Nytro

HACKING EXPOSED™ 6: NETWORK SECURITY SECRETS & SOLUTIONS STUART MCCLURE JOEL SCAMBRAY GEORGE KURTZ CONTENTS Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Part I Casing the Establishment Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 IAAAS—It’s All About Anonymity, Stupid . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Tor-menting the Good Guys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 ? 1 Footprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 What Is Footprinting? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Why Is Footprinting Necessary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Internet Footprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Step 1: Determine the Scope of Your Activities . . . . . . . . . . . . . . . . . . 10 Step 2: Get Proper Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Step 3: Publicly Available Information . . . . . . . . . . . . . . . . . . . . . . . . . 11 Step 4: WHOIS & DNS Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Step 5: DNS Interrogation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Step 6: Network Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 ? 2 Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Determining If the System Is Alive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Determining Which Services Are Running or Listening . . . . . . . . . . . . . . . . 54 Scan Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Identifying TCP and UDP Services Running . . . . . . . . . . . . . . . . . . . . 56 Windows-Based Port Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Port Scanning Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 xiv Hacking Exposed 6: Network Security Secrets & Solutions Detecting the Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Active Stack Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Passive Stack Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 ? 3 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Basic Banner Grabbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Enumerating Common Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Part II System Hacking Case Study: DNS High Jinx—Pwning the Internet . . . . . . . . . . . . . . . . . . . . . 152 ? 4 Hacking Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 What’s Not Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Unauthenticated Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Authentication Spoofi ng Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Remote Unauthenticated Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Authenticated Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Privilege Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Extracting and Cracking Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Remote Control and Back Doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Port Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Covering Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 General Countermeasures to Authenticated Compromise . . . . . . . . 202 Windows Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Windows Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Automated Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Security Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Security Policy and Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Bitlocker and the Encrypting File System (EFS) . . . . . . . . . . . . . . . . . 211 Windows Resource Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Integrity Levels, UAC, and LoRIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Data Execution Prevention (DEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Service Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Compiler-based Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Coda: The Burden of Windows Security . . . . . . . . . . . . . . . . . . . . . . . . 220 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 ? 5 Hacking Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 The Quest for Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 A Brief Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Contents xv Vulnerability Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Remote Access vs. Local Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Data-Driven Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 I Want My Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Common Types of Remote Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Local Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 After Hacking Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 What Is a Sniffer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 How Sniffers Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Popular Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Rootkit Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Part III Infrastructure Hacking Case Study: Read It and WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 ? 6 Remote Connectivity and VoIP Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Preparing to Dial Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 War-Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Legal Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Peripheral Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Brute-Force Scripting—The Homegrown Way . . . . . . . . . . . . . . . . . . . . . . . . 336 A Final Note About Brute-Force Scripting . . . . . . . . . . . . . . . . . . . . . . 346 PBX Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Voicemail Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Virtual Private Network (VPN) Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Basics of IPSec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Voice over IP Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Attacking VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 ? 7 Network Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Autonomous System Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Normal traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 traceroute with ASN Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 show ip bgp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Public Newsgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Service Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 xvi Hacking Exposed 6: Network Security Secrets & Solutions Network Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 OSI Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 OSI Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 OSI Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Misconfi gurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Route Protocol Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Management Protocol Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 ? 8 Wireless Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Wireless Footprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 War-Driving Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Wireless Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 Wireless Scanning and Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Wireless Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Wireless Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Identifying Wireless Network Defenses and Countermeasures . . . . . . . . . . 470 SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 MAC Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Gaining Access (Hacking 802.11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 MAC Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 Attacks Against the WEP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Tools That Exploit WEP Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 LEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 Attacks Against the WPA Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 ? 9 Hacking Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Physical Access: Getting in the Door . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 Hacking Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Default Confi gurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Owned Out of the Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Standard Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Reverse Engineering Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Mapping the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Sniffi ng Bus Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Firmware Reversing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 Contents xvii Part IV Application and Data Hacking Case Study: Session Riding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 ? 10 Hacking Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Common Exploit Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Buffer Overfl ows and Design Flaws . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Input Validation Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527 Common Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 People: Changing the Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530 Process: Security in the Development Lifecycle (SDL) . . . . . . . . . . . . 532 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 Recommended Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 ? 11 Web Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 Web Server Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Source Code Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Canonicalization Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 Server Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 Buffer Overfl ows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 Web Server Vulnerability Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 Web Application Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 Finding Vulnerable Web Apps with Google . . . . . . . . . . . . . . . . . . . . . 553 Web Crawling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 Web Application Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Common Web Application Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 ? 12 Hacking the Internet User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585 Internet Client Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 A Brief History of Internet Client Hacking . . . . . . . . . . . . . . . . . . . . . . 586 JavaScript and Active Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591 Cross-Site Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 Cross-Frame/Domain Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 594 SSL Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 Payloads and Drop Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 E-Mail Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 Instant Messaging (IM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 Microsoft Internet Client Exploits and Countermeasures . . . . . . . . . 604 General Microsoft Client-Side Countermeasures . . . . . . . . . . . . . . . . 609 Why Not Use Non-Microsoft Clients? . . . . . . . . . . . . . . . . . . . . . . . . . . 614 xviii Hacking Exposed 6: Network Security Secrets & Solutions Socio-Technical Attacks: Phishing and Identity Theft . . . . . . . . . . . . . . . . . . . 615 Phishing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 Annoying and Deceptive Software: Spyware, Adware, and Spam . . . . . . . 619 Common Insertion Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 Blocking, Detecting, and Cleaning Annoying and Deceptive Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Malware Variants and Common Techniques . . . . . . . . . . . . . . . . . . . . 623 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 Part V Appendixes Download: http://www50.zippyshare.com/v/55127603/file.html

Mozilla Fixes 10 Vulnerabilities with Firefox 25 by Chris Brook Mozilla released the 25th version of its mobile and desktop Firefox browser yesterday, fixing 10 vulnerabilities, five of them critical. The United States Computer Emergency Readiness Team (US-CERT) warned yesterday the vulnerabilities could let an attacker execute arbitrary code, bypass access restrictions, obtain sensitive information and cause a denial-of-service (DoS) condition. According to the Mozilla Security Foundation Advisory, the critical fixes address a few problems, namely a series of use-after-free bugs and memory bugs in the JavaScript engine that can open the system up to attackers and lead to a crash. While not critical, another bug discovered by security researcher Cody Crews was patched that could have let an attacker append an iFrame into an embedded PDF object. The result could have led to the disclosure of local system files and the bypassing of security restrictions. According to the company’s bug-tracking database Bugzilla, 565 bugs in total were fixed in Firefox 25.0. While Mozilla’s Thunderbird mail client (24.1) and Seamonkey (2.22) Internet application suite were also updated yesterday, most of the bugs fixed were only at risk of being exploited in the Firefox browser or Firefox “browser-like contexts.” Since scripting is disabled in Thunderbird and Seamonkey, it makes them less likely to be exploited. Mozilla’s mobile version got an upgrade yesterday as well, bringing some existing security features from the desktop browser to Android devices. One of those features, mixed content blocking, introduced in the main Firefox browser back in August should protect users from man-in-the-middle attacks and eavesdroppers on HTTPS pages. The feature reduces the threat of insecure images, audio and JavaScript on HTTPS pages by blocking them by default. The latest mobile build also supports guest browsing, making it easier for users to lend their device to others without having them have to worry about revealing any sensitive bookmarks or history. Both guest browsing and mixed content blocking features were introduced in the beta version of the mobile browser back in September but officially went live in the stable version yesterday. Per usual, both versions of Firefox, for mobile and desktop, along with updated versions of Thunderbird and Seamonkey are available at their respective download pages. Sursa: Mozilla Fixes 10 Vulnerabilities with Firefox 25 | Threatpost | The First Stop For Security News

Critical vulnerability in Twitter allows attacker to upload Unrestricted Files Pierluigi Paganini, The Hacker News - Tuesday, October 29, 2013 Security expert Ebrahim Hegazy, Cyber Security Analyst Consultant at Q-CERT, has found a serious vulnerability in Twitter that allows an attacker to upload files of any extension including PHP. When an application does not validate or improperly validates file types before uploading files to the system, called Unrestricted File upload vulnerability. Such flaws allow an attacker to upload and execute arbitrary code on the target system which could result in execution of arbitrary HTML and script code or system compromise. According to Ebrahim, when a developer creates a new application for Twitter i.e. dev.twitter.com - they have an option to upload an image for that application. While uploading the image, the Twitter server will check for the uploaded files to accept certain image extensions only, like PNG, JPG and other extensions won’t get uploaded. But in a Video Proof of Concept he demonstrated that, a vulnerability allowed him to bypass this security validation and an attacker can successfully upload .htaccess and .PHP files to twimg.com server. Twimg.com is working as a CDN (content delivery network) which mean that every time attacker will upload a file, it will be hosted on a different server or subdomain of twimg.com. In CDN's usually scripting engines are not allowed to run. So, in normal scenarios a successful Exploitation of uploading htaccess & PHP files to a server that supports the PHP i.e. Remote Code Execution on that server. But in the case of Twitter: Vulnerability could be used to make twimg.com as a Botnet Command server by hosting a text file with commands, so infected machines would connect to that file to take its commands. Since twimg.com is a trusted domain by users so it won’t grab the attention. For hosting of malicious files. At least it could be used to upload a text page with a defacement content and then add the infected sub-domains of twimg.com as a mirror to Zone-h.org which would affect the reputation of Twitter. Twitter recognized the criticality of the Unrestricted File Upload Vulnerability and added Hegazy name to their Hall of Fame. I personally reached Ebrahim Hegazy that revealed me that he has also found an Open redirection Vulnerability in Twitter on 15th Sept. that has also been fixed. I conclude with a personal consideration, it's shame Twitter hasn't a bounty program, in my opinion is fundamental to incentive hackers to ethical disclosure of the bug. An attack against a social media could have serious repercussion on the users and on the reputation of the platform, if hackers sell the knowledge of the flaw on the black market a growing number of cyber criminals could benefit from it. Sursa: http://thehackernews.com/2013/10/critical-vulnerability-in-twitter.html

Articol scris de (stiu, acum o sa cititi): Swati Khandelwal - Working at 'The Hacker News'. Social Media Lover and Gadgets Girl. Speaker, Cyber Security Expert and Technical Writer.(Google+ Profile) Security researchers Adi Sharabani and Yair Amit have disclosed details about a widespread vulnerability in iOS apps, that could allow hackers to force the apps to send and receive data from the hackers' own servers rather than the legitimate ones they were coded to connect to. Speaking about the issue at RSA Conference Europe 2013 in Amsterdam, researchers have provided details on this vulnerability, which stems from a commonly used approach to URL caching. Demonstration shows that insecure public networks can also provide stealth access to our iOS apps to potential attackers using HTTP request hijacking methods. The researchers put together a short video demonstrating, in which they use what is called a 301 directive to redirect the traffic flow from an app to an app maker’s server to the attacker’s server. There are two limitations also, that the attacker needs to be physically near the victim for the initial poisoning to perform this attack and the flaw works only against HTTP traffic. “A victim walks into Starbucks, connects to the Wi-Fi and uses her favorite apps,” explains an example. “Everything looks and behaves as normal, however an attacker is sitting at a nearby table and performs a silent HRH attack on her apps. The next day, she wakes up at home and logs in to read the news, but she’s now reading the attacker’s news!” They estimate that at least 10,000 iOS apps in the Apple App Store are vulnerable to the hack. As a result, apps that display news, stock quotes, social media content, or even some online banking details can be manipulated to display fraudulent information and intercept data sent by the end user. Victims can uninstall apps to scrub their devices clean, and Skycure has released app code that prevents the web caching from taking place. It may be a while until developers can get this fix implemented, so connect to those public networks with extreme caution. Sursa: iOS apps vulnerable to HTTP Request Hijacking attacks over WiFi - The Hacker News

Facebook Tests Software to Track Your Cursor on Screen By Steve Rosenbush Facebook Inc.FB -0.62% is testing technology that would greatly expand the scope of data that it collects about its users, the head of the company’s analytics group said Tuesday. The social network may start collecting data on minute user interactions with its content, such as how long a user’s cursor hovers over a certain part of its website, or whether a user’s newsfeed is visible at a given moment on the screen of his or her mobile phone, Facebook analytics chief Ken Rudin said Tuesday during an interview. Facebook’s Ken Rudin Mr. Rudin said the captured information could be added to a data analytics warehouse that is available for use throughout the company for an endless range of purposes–from product development to more precise targeting of advertising. Facebook collects two kinds of data, demographic and behavioral. The demographic data—such as where a user lives or went to school—documents a user’s life beyond the network. The behavioral data—such as one’s circle of Facebook friends, or “likes”—is captured in real time on the network itself. The ongoing tests would greatly expand the behavioral data that is collected, according to Mr. Rudin. The tests are ongoing and part of a broader technology testing program, but Facebook should know within months whether it makes sense to incorporate the new data collection into the business, he said New types of data Facebook may collect include “did your cursor hover over that ad … and was the newsfeed in a viewable area,” Mr. Rudin said. “It is a never-ending phase. I can’t promise that it will roll out. We probably will know in a couple of months,” said Mr. Rudin, a Silicon Valley veteran who arrived at Facebook in April 2012 from Zynga Inc.ZNGA -3.12%, where he was vice president of analytics and platform technologies. As the head of analytics, Mr. Rudin is preparing the company’s infrastructure for a massive increase in the volume of its data. Facebook isn’t the first company to contemplate recording such activity. Shutterstock Inc.SSTK +0.75%, a marketplace for digital images, records literally everything that its users do on the site. Shutterstock uses the open-source Hadoop distributed file system to analyze data such as where visitors to the site place their cursors and how long they hover over an image before they make a purchase. “Today, we are looking at every move a user makes, in order to optimize the Shutterstock experience….All these new technologies can process that,” Shutterstock founder and CEO Jon Oringer told the Wall Street Journal in March. Facebook also is a major user of Hadoop, an open-source framework that is used to store large amounts of data on clusters of inexpensive machines. Facebook designs its own hardware to store its massive data analytics warehouse, which has grown 4,000 times during the last four years to a current level of 300 petabytes. The company uses a modified version of Hadoop to manage its data, according to Mr. Rudin. There are additional software layers on top of Hadoop, which rank the value of data and make sure it is accessible. The data in the analytics warehouse—which is separate from the company’s user data, the volume of which has not been disclosed—is used in the targeting of advertising. As the company captures more data, it can help marketers target their advertising more effectively—assuming, of course, that the data is accessible. “Instead of a warehouse of data, you can end up with a junkyard of data,” said Mr. Rudin, who spoke to CIO Journal during a break at the Strata and Hadoop World Conference in New York. He said that he has led a project to index that data, essentially creating an internal search engine for the analytics warehouse. Sursa: Facebook Considers Vast Increase in Data Collection - Digits - WSJ

Deep C and C++ Dragi programator C/C++, cititi: http://www.slideshare.net/olvemaudal/deep-c

Researcher Finds Method to Insert Malicious Firmware Into Currency Validator by Dennis Fisher If espionage is the world’s second-oldest profession, counterfeiting may be in the running to be third on that list. People have been trying to forge currency for just about as long as currency has been circulating, and anti-counterfeiting methods have tried to keep pace with the state of the art. The anti-counterfeiting technology in use today of course relies on computers and software, and like all software, it has bugs, as researchers at IOActive discovered when they reverse-engineered the firmware in a popular Euro currency verifier and found that they could insert their own firmware and force the machine to verify any piece of paper as a valid Euro note. Ruben Santamarta, a researcher at IOActive in Spain, decided to have a look at the firmware in a machine called the Secureuro, which is used widely in that country to verify Euro notes in a variety of settings. After watching some videos from the vendor Inves on the machine’s operations and reading through the machine’s documentation, Santamarta came to the conclusions that some of the security claims the vendor makes were somewhat specious. “Unfortunately, some of these claims are not completely true and others are simply false. It is possible to understand how Secureuro works; we can access the firmware and EEPROM without even needing hardware hacking. Also, there is no encryption system protecting the firmware,” Santamarta said in his analysis of the firmware. “My intention is not to forge a banknote that could pass as legitimate, that is a criminal offense. My sole purpose is to explain how I identified the code behind the validation in order to create ‘trojanized’ firmware that accepts even a simple piece of paper as a valid currency. We are not exploiting a vulnerability in the device, just a design feature.” In that regard, Santamarta succeeded. He began by downloading the firmware for the Secureeuro from the vendor’s site and then performing a detailed analysis of the code to see how it works and what the important functions are. He found a number of interesting functions in the firmware and one of the things he came across was the counter that increments the number of invalid banknotes the machine has counted. “Wait, hold on a second, the number of invalid banknotes is being stored in a three byte counter in the EEPROM, starting at position 0xE. Are you thinking what I’m thinking? We should look for the opposite operation. Where is that counter being incremented? That path would hopefully lead us to the part of code where a banknote is considered valid or invalid Keep calm and ‘EEPROM_write’ Bingo!” Santamarta wrote. Digging a bit further, Santamarta discovered that there are two functions that assign a value to a given bank note. One assigns a preliminary value and the second one assigns a final value for each note. He determined that the firmware may be processing some of the security features of a note, such as the ink or a hologram, with one function and then processing another set with the second function. He identified a separate function that performs some analog-to-digital conversion of input. “This function receives the input pin from the ADC conversion as a parameter. As expected, it is invoked to complete the conversion of six different pins; inside a timer. The remaining three digital signals with information about the distances can also be obtained easily,” he said. “The last step was to buy the physical device. I modified the original firmware to accept our home-made IOActive currency, and…what do you think happened? “The impact is obvious. An attacker with temporary physical access to the device could install customized firmware and cause the device to accept counterfeit money. Taking into account the types of places where these devices are usually deployed (shops, mall, offices, etc.) this scenario is more than feasible.” So Santamarta’s technique could enable an attacker to load his own malicious firmware onto a target device and validate counterfeit money. Euros, like other widely circulated currencies, have a number of security and anti-counterfeiting features and Santamarta’s research shows that it’s not necessary to circumvent those in order to pass counterfeit notes. The easier method is to attack the validator itself, rather than the notes. Sursa: Researcher Finds Method to Insert Malicious Firmware Into Currency Validator | Threatpost | The First Stop For Security News

Interview: Bjarne Stroustrup Discusses C++ Bjarne Stroustrup and William Wong C and C++ are the main programming languages for embedded computing and for a host of other application areas as well. C++ was developed by Bjarne Stroustrup and he was gracious enough to answer a few of my questions about C++ and its development. He not only developed the initial version of C++ but has been actively involved in updating through the latest standard, C++11. He has also taught and written about C++ with books like “Programming: Principles and Practice using C++.” Wong: How did you get started designing C++? Stroustrup: I needed a tool to help me on a project where I needed hardware access, high performance for systems programming tasks, and help with handling complexity. The project was to “split” a Unix kernel into parts that could run on a multi-processor or a high-performance local network. At the time (1979/80), no language could meet all three requirements, so I added Simula-like classes to C. The earliest designs added function argument checking and conversion (what later became C function prototypes), constructors and destructors, and simple inheritance. Interestingly, my earliest paper on “C with Classes” as it was called in the early years, used macros to implement a simple form of generic programming – later I found that didn’t scale and I had to add templates. Over the next few years, my design (and implementation) was refined until the commercial release of C++ in 1985. Performance and hardware access was very important in the early years – as it still is. I considered it essential to be able to do everything C could do and to do it at least as efficiently. For example, early on, I found that to handle copy constructors, I had introduced a 3% overhead for returning structure values compared to C. I considered that unacceptable and by the end of the week the overhead was gone. Function call inlining was introduced to be able to handle interrupts in an embedded processor without the overhead of a function call and without forcing programmers to abandon classes to handle interrupts. The idea that facilities shouldn’t just be expressive and elegant, but also needed to be affordable in the most demanding applications was very important to me. Wong: What were/are the major design goals for C++? Stroustrup: A way of mapping C++ language features to machine facilities that is at least as direct and efficient as C’s plus abstraction mechanisms that allows programmers to express ideas beyond what I can imagine with no overhead compared to hand-crafted code. This implies static (compile-time) type checking. C++ was and is meant to be a tool for professionals and for people who takes programming seriously. It can and is used by novices, but the too often heard complaint that “C++ isn’t for everybody and not every project is easily done using C++” is based on a seriously miscomprehension. There can be no programming language that is perfect for everybody and for everything. C++ doesn’t try to be everything for everybody, but it is rather good at the tasks for which it was designed – mostly systems programming, software infrastructure, and resource-constrained applications. C++ dominates the fields where its strengths are needed. The fact that you can write a simple web app easier using JavaScript or Ruby does not bother me. Basically, C++ was not primarily designed for tasks of medium complexity, medium performance, and medium reliability, written by programmers of medium skills and experience. Obviously, it can be used for that and is widely used for that, but that’s not its areas of specific strength compared to many other languages. I documented my design aims and the constraints on the design in my book “The Design and Implementation of C++” and in my two History of Programming Languages conference papers, but briefly, I aim for zero overhead compared to hand-crafted code when using abstractions, a machine model very similar to that of C, an extremely flexible set of abstraction mechanism, and static type safety. The overall aim is to help produce better code for challenging real-world tasks, and “to make programming more pleasant for the serious programmer.” Obviously, I can’t get all of what I would like in every situation. So C++ isn’t perfect. However, Despite innumerable attempts to displace it, C++ is still the best match for its stringent design criteria and for a huge range of real-world problems. Wong: You have been working with the standard since it started. How has it changed over time and where is it headed? Stroustrup: That’s hard to say. Formal standardization is a very hard and often tedious task. The people involved are usually clever and experienced, but they come from very diverse backgrounds and often represent major industrial interests, so constructing a consensus can be very difficult and is time consuming. Creating a consensus is essential because there is no way to force implementers to provide a faithful version of the standard and no way of forcing programmers to use novel features. Only by providing something almost universally agreed to be genuinely useful can we make progress. A standard committee is no place for single-issue fanatics. My estimate is that close to 100 organizations and maybe 300+ individuals are involved. That’s two to three times the numbers in the early years. We have had close to 100 people attending recent meetings. Our plan is to issue a new standard with minor new features and corrections in 2014, C++14. This will almost certainly happen because we have already had national body votes on the changes and implementations of every new feature are available somewhere. I expect to be using C++14 in 2014. After that, there is a plan for C++17 in 2017. That will be a more major upgrade, so I can’t be quite as optimistic about the timing. The ISO C++ standards committee has no resources (money, time, developers). The members actually have to pay $1200 a year to participate. If you don’t like what we do, don’t just complain. Don’t just say “I want a GUI library” or “there is no proper support for task-based concurrency” or whatever. We know that. Instead, come help us to get the work done right. We are always short of experienced application builders, so novel features have tendency to overly reflect the interests of implementers and library builders. Wong: Many embedded designers choose to use C because “it is simpler and closer to the hardware” than C++. Do you think that complexity of C++ should be a deterrent to embedded designers? Stroustrup: No. C isn’t simpler for C-style programming than C++ is, nor “closer to the hardware,” nor indeed more efficient. I have yet to see a program that can be written better in C than in C++. I don’t believe such a program could exist. By “better” I mean smaller, more efficient, or more maintainable. The myth that “C is simpler and more efficient” have caused (and causes) untold numbers of beginners to concentrate on obscure workarounds and difficult-to-master techniques, rather than learning how to use more powerful supporting features. Many then fall in love with their obscure and complex code, considering it a sign of expert knowledge. It is amazing what people can fail to learn when they are told that it is difficult and useless. The only reason I know of to use “plain C” rather than a suitable subset of C++ is lack of tool support on a given platform. We can’t just blame the beginners/novices/students, though. The presentation and teaching of C++ has been a constant problem. Almost a decade ago, when I first was to teach programming to freshman engineering students, I looked at the textbooks using C++ and despaired. More precisely, I did not despair, I was furious! There were (and are) books teaching every little obscure detail of C before getting to the far-easier-to-use C++ alternatives, and deeming those alternatives “advanced” to scare off all but the most determined student. Seriously, how could a standard-library vector be as hard to use well as a built-in array? How could using qsort() be simpler than using the more general and efficient sort()? C++ provides better notational support and stronger type checking than C does. This can lead to faster object code. Other books presented (and presents) C++ as a somewhat failed attempt to be a “pure object oriented programming language” and force most every operation into class hierarchies (a la Java) with lots of inheritance and virtual functions. The result is verbose code with unnatural couplings, and lots of casting. To add insult to injury, such code also tends to be slow. As I said: if that’s C++, I don’t like it either! I responded by writing a textbook for college freshmen and determined self-learners: “Programming: Principles and Practice using C++.” It does not assume previous programming experience, though it has been popular with programmers wanting to know what C++ is about. That book is a bit long for experienced programmers wanting a quick look at what C++11 is like. For that I recommend “A Tour of C++” which presents all the major features of ISO C++ and its standard library in just 180 pages! C++11 is completely supported by Clang and GCC, and partially by Microsoft C++ and many other implementations. I fear that C++11 support is still be a bit spotty of less mainstream systems. Wong: C++11 has added a number of features including lambdas and threading support. How has your view of features like these changed over time? Stroustrup: I have wanted thread support in the standard for at least 15 years. Now I finally got it after having to have to use nice, but non-standard, thread libraries for decades. C++11’s contribution to concurrent programming is the memory model (now also adopted by C) and to make traditional threads-and-locks level programming portable and type-safe. That’s major. No macros and void**s are needed to share information and pass information between threads. For some, the facilities for lock-free programming are also important. I have been concerned about lambdas for a while (maybe a decade), looking for a variant of the (inherently good) idea that would do more good than harm in the context of C++. The performance of the library versions were not sufficiently good, but the performance of the current implementations of C++11 lambdas (in current compilers) is as good as that of equivalent for-loop bodies. For example: double sum = 0; for (int I =0; i<v.size(); ++i) sum += v[i]; // array style and double sum = 0; for (auto p = v.begin(); p!=v.end(); ++p) sum += *p; // pointer style and double sum = 0; for_each(v.begin(),v.end(), [&](double d) { sum += d; }); // algorithm style These alternatives now run at exactly the same speed on all major C++ compilers. That is, we can now choose between those styles based on aesthetics, maintainability, etc. There are quite a few places where I use lambdas in preference to alternatives. For example: sort(v, [](const string& a, const string& b) { return a>b; }); // sort in reverse order That said, lambdas is a new and powerful feature. Such features are always overused until the community learns what pays off in the long run. In my opinion, it is often worthwhile to separately define a function or a function object so that the operation can have a specific name, can be used from multiple places in a program and where there is space for a helpful comment. Lambdas can easily become and exercise in write-only code. This is not the place to teach C++11, but let me give just one example: template<typename C, typename V> vector<Value_type<C>*> find_all(C& cont, V v) // find all occurrences of v in cont { vector<Value_type<C>*> res; for (auto& x : cont) if (x==v) res.push_back(&x); return res; } Here, I use several new features. The new for-loop, a range-for loop, is read “for all x in cont” and simplifies traversing the container cont. The auto& x declaration says that the type of x should be a reference to the type of the elements in the initializer of x, that is, a reference to the type of elements in cont. The loop collects the addresses of all occurrences of v in cont in the vector of pointers res. So far, the new features here have been merely “syntactic sugar,” but these are rather nice and useful notational improvements. The real novelty here is the return statement: Note that I return a potentially huge vector by value. In C++98, that would typically cause the copy of all elements of res, potentially many thousands of elements. That would be a serious performance bug. In C++11, vector has a “move constructor,” so that rather than copying elements, the representation of res (merely three pointers) is “stolen” for use in the caller and an empty vector is left behind. After all, we are just about to return from find_all() and won’t be able to use res again. Thus, returning a vector by value costs at most six word assignments independently of the number of elements. Move constructors is a simple facility available to every programmer and used by all standard-library containers implemented as handles. This allows us to return large objects from a function without messing around with memory management (explicitly) using pointers and free store. We can test find_all() like this: void test() { string m {"Mary had a little lamb"}; for (const auto p : find_all(m,'a')) // p is a char* if (*p!='a') cerr << "string bug!\n"; vector<string> v {"Mary”, “lamb", “Mary”, “mary”, “wolf”}; for (const auto p : find_all(v,”Mary”)) // p is a string* if (*p!=”Mary”) cerr << "vector<string> bug!\n"; } Feel free to compare this to a hand-crafted version without templates or C++11 features. For more information, read “A Tour of C++.” For all the details see “The C++ Programming Language (Fourth Edition).” Wong: What common mistakes do you see new C++ developers making? Stroustrup: They think they have to choose between “efficiency” and elegance, so they either stick to a small low-level subset (“for efficiency”) or build bloated “do-everything” designs (deeming those elegant). My ideal is for the most efficient code also to be the most elegant. That happens when you have a perfect fit between a problem and a solution. Obviously, you can’t always achieve that and you rarely achieve it at the first try, but it happens often enough for the ideal to be of practical relevance. Before dismissing C++ features, such as classes and templates, for demanding tasks, learn the basics of their use and try them out. Measure, rather than guessing about performance! Do not feel obliged to craft huge hierarchies or write complicated template meta-programs. Some of the most powerful C++ features are quite simple and leads to good object code. One of the best ways to get efficient code is to write simple source code. Wong: What do you like to do for fun? Stroustrup: Travel to interesting places, run, take photographs, listen to music, read (literature and history), spend time with family and friends. Of course, some of my programming is great fun also, but I guess you weren’t asking about work. Research and advanced system building is fun. As they say “I can’t believe we are getting paid for doing this!” Sursa: Interview: Bjarne Stroustrup Discusses C++ | Dev Tools content from Electronic Design

[h=1]Car hackers mess with speedos, odometers, alarms and locks[/h]By Darren Pauli on Oct 29, 2013 5:10 PM If you lend your car to Ted Sumers and Grayson Zulauf, there's a good chance it'll never work the same again. You might even get it back on a tow truck. The duo weren't street hoons but rather a pair of capable hardware hackers who know how to mess with a car's speedometre, brakes and alert systems. They were the latest in a burgeoning scene of academics and security boffins who along with a thriving but fragmented assortment of rev-head hobbyist geeks are battering the digital fabric powering modern-day cars. When Sumers and Zulauf began their research, they did not let the lack of computer documentation, the exorbitant costs of proprietary computer analysis kits or tight-lipped mechanics stop them. Speaking at the Breakpoint security conference in Melbourne, the researchers from automtive startups Automatic and Motiv Power Systems told how together with Chris Hoder of Microsoft the trio set off to discover how the digital bits flew around Controller Area Networks (CANs) embedded into many cars in use today. With physical access to the cars the men were able to make vehicles appear to drive slower than actual speed, manipulate brakes, alarms and unlock doors. They could also increase a car's odometer and with further research wind it back. Other researchers have accessed car networks via bluetooth and developed ways to compromise autos through firmware. The capabilities of CAN hacking were vast. In August, researchers Charlie Miller and Chris Valasek tapped into CANs to cut the brakes of a Ford Escape and caused the wheel of a Ford Focus to jerk out of the hands of a driver at high speed. Other hobbyists have used CAN bus hacking to alter functions such as the fuel injection levels of cars with some creating legitimate car customisation businesses using their skills. Criminals too have benefitted. Sumers said recent years a criminal gang sold a device they created to unlock doors for pricey Audis via a port that remarkably could be accessed from an exterior panel on the vehicle. A spate of car thefts resulted until their arrest. But much of the important parts of the research needed to start hacking CANs was not available, the researchers said. This forced them in their bid to deliver a project for the University of Dartmouth and open the field to others to effectively "start from ground zero". After initial trial and error -- and the purchase of a second car -- they gained access to the CAN and began fuzzing against to identitfy which of the arbitration ID packets were sent to particular components of the vehicle such as the speedometre, brakes and dashboard indicators. "The car started making horrible noises -- every light on the dashboard was blinking," Zulauf said. "If you do this yourself you might want to use a friend's car," Sumers added. Like other consumer products such as smart TVs and network-connected white goods, most vehicles were designed for functionality and paid little or no homage to security. The trio, for example, found that CAN transmissions contained no authentication requirements because car designers built the architecture with the intent it would operate in closed secure environments. Sumers said manufacturers would unlikely be able to introduce authentication because it would slow down the CANs too much. Indeed Ford and Toyota have not moved to fix the weaknesses, saying that the hacking scenarios were academic and did not place drivers at risk. The CANs also ran as single networks within all but the high-end vehicles -- notably the "over-engineered" German autos -- meaning that their fuzzing efforts were easier. Their fuzzing processes worked by a system of sniffing, searching and probing using Travis Goodspeed's GoodTHOPTER10. They would monitor CAN packets, find those that appeared interesting and then seek out what systems within the cars that they controlled. Breakpoint 2013 Inside car CAN hacking by Darren Pauli on Mixcloud The trio were keen for others to enter the hacking field and have produced a $25 open-modular source hardware tool for reading CANs that has the capability of those worth tens of thousands. "The more people play with it, the better it will get," Sumers said, adding that he was keen to learn how different CAN implementations were. Copyright © SC Magazine, Australia Sursa: http://www.scmagazine.com.au/News/362297,car-hackers-mess-with-speedos-odometers-alarms-and-locks.aspx

Trebuia sa le sparga muie ratatilor de la ProTV. NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say - The Washington Post

Table of Contents Cryptography and Computation Practical Covertly Secure MPC for Dishonest Majority – Or: Breaking the SPDZ Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Ivan Damg?ard, Marcel Keller, Enrique Larraia, Valerio Pastro, Peter Scholl, and Nigel P. Smart Practical and Employable Protocols for UC-Secure Circuit Evaluation over Zn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Jan Camenisch, Robert R. Enderlein, and Victor Shoup Privacy-Preserving Accountable Computation . . . . . . . . . . . . . . . . . . . . . . . 38 Michael Backes, Dario Fiore, and Esfandiar Mohammadi Measurement and Evaluation Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Benjamin S. Lerner, Liam Elberty, Neal Poole, and Shriram Krishnamurthi A Quantitative Evaluation of Privilege Separation in Web Browser Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Xinshu Dong, Hong Hu, Prateek Saxena, and Zhenkai Liang Estimating Asset Sensitivity by Profiling Users . . . . . . . . . . . . . . . . . . . . . . 94 Youngja Park, Christopher Gates, and Stephen C. Gates Applications of Cryptography Practical Secure Logging: Seekable Sequential Key Generators . . . . . . . . . 111 Giorgia Azzurra Marson and Bertram Poettering Request-Based Comparable Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Jun Furukawa Ensuring File Authenticity in Private DFA Evaluation on Encrypted Files in the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Lei Wei and Michael K. Reiter XIV Table of Contents Code Analysis HI-CFG: Construction by Binary Analysis and Application to Attack Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Dan Caselden, Alex Bazhanyuk, Mathias Payer, Stephen McCamant, and Dawn Song AnDarwin: Scalable Detection of Semantically Similar Android Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Jonathan Crussell, Clint Gibler, and Hao Chen BISTRO: Binary Component Extraction and Embedding for Software Security Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Zhui Deng, Xiangyu Zhang, and Dongyan Xu Network Security Vulnerable Delegation of DNS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Amir Herzberg and Haya Shulman Formal Approach for Route Agility against Persistent Attackers . . . . . . . . 237 Jafar Haadi Jafarian, Ehab Al-Shaer, and Qi Duan Plug-and-Play IP Security: Anonymity Infrastructure instead of PKI . . . 255 Yossi Gilad and Amir Herzberg Formal Models and Methods Managing the Weakest Link: A Game-Theoretic Approach for the Mitigation of Insider Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Aron Laszka, Benjamin Johnson, Pascal Sch¨ottle, Jens Grossklags, and Rainer B¨ohme Automated Security Proofs for Almost-Universal Hash for MAC Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Martin Gagn´e, Pascal Lafourcade, and Yassine Lakhnech Bounded Memory Protocols and Progressing Collaborative Systems . . . . 309 Max Kanovich, Tajana Ban Kirigin, Vivek Nigam, and Andre Scedrov Universally Composable Key-Management . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Steve Kremer, Robert K¨unnemann, and Graham Steel Table of Contents XV Protocol Analysis A Cryptographic Analysis of OPACITY (Extended Abstract) . . . . . . . . . . 345 ¨ Ozg¨ur Dagdelen, Marc Fischlin, Tommaso Gagliardoni, Giorgia Azzurra Marson, Arno Mittelbach, and Cristina Onete Symbolic Probabilistic Analysis of Off-Line Guessing . . . . . . . . . . . . . . . . . 363 Bruno Conchinha, David Basin, and Carlos Caleiro ASICS: Authenticated Key Exchange Security Incorporating Certification Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Colin Boyd, Cas Cremers, Mich`ele Feltz, Kenneth G. Paterson, Bertram Poettering, and Douglas Stebila Privacy Enhancing Models and Technologies Efficient Privacy-Enhanced Familiarity-Based Recommender System . . . . 400 Arjan Jeckmans, Andreas Peter, and Pieter Hartel Privacy-Preserving User Data Oriented Services for Groups with Dynamic Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Dmitry Kononchuk, Zekeriya Erkin, Jan C.A. van der Lubbe, and Reginald L. Lagendijk Privacy-Preserving Matching of Community-Contributed Content . . . . . . 443 Mishari Almishari, Paolo Gasti, Gene Tsudik, and Ekin Oguz E-voting and Privacy Ballot Secrecy and Ballot Independence Coincide . . . . . . . . . . . . . . . . . . . . 463 Ben Smyth and David Bernhard Election Verifiability or Ballot Privacy: Do We Need to Choose? . . . . . . . 481 ´ Edouard Cuvelier, Olivier Pereira, and Thomas Peters Enforcing Privacy in the Presence of Others: Notions, Formalisations and Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Naipeng Dong, Hugo Jonker, and Jun Pang Malware Detection Mining Malware Specifications through Static Reachability Analysis . . . . 517 Hugo Daniel Macedo and Tayssir Touili Patrol: Revealing Zero-Day Attack Paths through Network-Wide System Object Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 Jun Dai, Xiaoyan Sun, and Peng Liu XVI Table of Contents Measuring and Detecting Malware Downloads in Live Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Phani Vadrevu, Babak Rahbarinia, Roberto Perdisci, Kang Li, and Manos Antonakakis Access Control Automated Certification of Authorisation Policy Resistance . . . . . . . . . . . 574 Andreas Griesmayer and Charles Morisset Fine-Grained Access Control System Based on Outsourced Attribute-Based Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 Jin Li, Xiaofeng Chen, Jingwei Li, Chunfu Jia, Jianfeng Ma, and Wenjing Lou Purpose Restrictions on Information Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 Michael Carl Tschantz, Anupam Datta, and Jeannette M. Wing Distributed Shuffling for Preserving Access Confidentiality . . . . . . . . . . . . 628 Sabrina De Capitani di Vimercati, Sara Foresti, Stefano Paraboschi, Gerardo Pelosi, and Pierangela Samarati Attacks Range Extension Attacks on Contactless Smart Cards . . . . . . . . . . . . . . . . 646 Yossef Oren, Dvir Schirman, and Avishai Wool CellFlood: Attacking Tor Onion Routers on the Cheap . . . . . . . . . . . . . . . . 664 Marco Valerio Barbera, Vasileios P. Kemerlis, Vasilis Pappas, and Angelos D. Keromytis Nowhere to Hide: Navigating around Privacy in Online Social Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682 Mathias Humbert, Th´eophile Studer, Matthias Grossglauser, and Jean-Pierre Hubaux Current Events: Identifying Webpages by Tapping the Electrical Outlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Shane S. Clark, Hossen Mustafa, Benjamin Ransford, Jacob Sorber, Kevin Fu, and Wenyuan Xu Language-Based Protection Eliminating Cache-Based Timing Attacks with Instruction-Based Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 Deian Stefan, Pablo Buiras, Edward Z. Yang, Amit Levy, David Terei, Alejandro Russo, and David Mazi`eres Table of Contents XVII Data-Confined HTML5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736 Devdatta Akhawe, Frank Li, Warren He, Prateek Saxena, and Dawn Song KQguard: Binary-Centric Defense against Kernel Queue Injection Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755 Jinpeng Wei, Feng Zhu, and Calton Pu Run-Time Enforcement of Information-Flow Properties on Android (Extended Abstract) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775 Limin Jia, Jassim Aljuraidan, Elli Fragkaki, Lujo Bauer, Michael Stroucken, Kazuhide Fukushima, Shinsaku Kiyomoto, and Yutaka Miyake Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 Da, not bad

https://www.exodusintel.com/files/Aaron_Portnoy-Bypassing_All_Of_The_Things.pdf

Software Defense: mitigating heap corruption vulnerabilities swiat 29 Oct 2013 4:10 AM Heap corruption vulnerabilities are the most common type of vulnerability that Microsoft addresses through security updates today. These vulnerabilities typically occur as a result of programming mistakes that make it possible to write beyond the bounds of a heap buffer (a spatial issue) or to place a heap allocated object in an unexpected state such as by using the object after it has been freed (a temporal issue). Over time, attackers have developed a number of techniques to help them exploit various types of heap corruption vulnerabilities. Starting with Windows XP Service Pack 2, Microsoft began introducing hardening changes to the Windows heap manager that were designed to make it more difficult to exploit heap corruption vulnerabilities. In this blog post, we will review some of the general methods that have been used to exploit and mitigate heap corruption vulnerabilities and highlight hardening changes that have been made in Windows 8 and Windows 8.1 to further complicate exploitation. For more background on the Windows 8 heap architecture, please refer to the Channel 9 interview on the Windows 8 heap manager. Heap corruption exploitation, then and now In a previous blog post, we covered the history of heap-based exploitation and mitigation techniques from Windows XP through Windows 7. This blog post showed that prior to Windows Vista, most of the research on heap corruption exploitation techniques focused on corrupting heap metadata in order to achieve more powerful exploitation primitives (such as the ability to write an arbitrary value to any location in memory). One of the reasons attackers focused on corrupting heap metadata is because it was always present and therefore could enable application-independent (generic) exploitation techniques. The release of Windows Vista changed the landscape of heap exploitation through numerous heap hardening changes that addressed nearly all of the heap metadata corruption exploitation techniques that were known at the time. As a consequence of the hardening changes in Windows Vista, attackers have largely shifted their focus toward exploitation techniques that rely on corrupting application-specific data stored on the heap. For example, attackers will attempt to use a heap corruption vulnerability to corrupt the C++ virtual table pointer of an object on the heap or to corrupt the base or length field of a heap-allocated array to achieve the ability to read or write to any location in memory. There has been additional research on heap metadata corruption post-Windows Vista and there are a small number of known real-world exploits that have relied on these metadata corruption techniques[1,2,3,4], but as this blog post will show, all of the publicly known exploitation techniques that rely on metadata corruption have been addressed in Windows 8.1. Heap corruption mitigations The heap manager in Windows 8 and Windows 8.1 builds on the hardening changes of previous Windows releases by incorporating new security features that mitigate not only metadata corruption techniques but also less generic techniques that rely on corrupting application-specific data. These new security features can be broken down into the following threat categories: heap integrity checks, guard pages, and allocation order randomization. All of the security features introduced in Windows 8 have been inherited by Windows 8.1. Heap integrity checks The heap manager in Windows 8 and Windows 8.1 includes a number of new integrity checks that are designed to detect heap metadata corruption and terminate an application safely if corruption is detected. This section describes some of the noteworthy integrity checks that have been added. Catch-all exception handling blocks have been removed Previous versions of the Windows heap made use of catch-all exception handling blocks in certain cases where exceptions were considered non-fatal. This had the potential to make it easier for attackers to exploit heap corruption issues in certain cases, in particular by allowing an attacker multiple attack attempts. Therefore, these catch-all blocks have been removed from the heap in Windows 8, meaning such exceptions now lead to safe termination of the application. HEAP handle can no longer be freed The HEAP handle is an internal data structure that is used to maintain the state associated with a given heap. Prior to Windows 8, an attacker could use a heap-based memory corruption vulnerability to coerce the heap into freeing the HEAP handle data structure. After doing this, the attacker could force the heap to reallocate the memory that previously stored the HEAP handle state. This in turn allowed an attacker to corrupt internal heap metadata, including certain function pointer fields. The Windows 8 heap mitigates this attack by preventing a HEAP handle from being freed. HEAP CommitRoutine encoded by a global key The HEAP handle data structure includes a function pointer field called CommitRoutine that is called when memory regions within the heap are committed. Starting with Windows Vista, this field was encoded using a random value that was also stored as a field in the HEAP handle data structure. While this mitigated trivial corruption of only the CommitRoutine function pointer, it did not mitigate the case where an attacker could corrupt both the CommitRoutine and the field that stored the encoding key. The Windows 8 heap mitigates this attack by using a global key to encode the CommitRoutine function pointer rather than a key that is stored within the HEAP handle data structure. Extended block header validation Each heap allocation returned by the Windows heap has a header that describes the allocation’s size, flags, and other attributes. In some cases, the Windows heap may flag an allocation as having an extended block header which informs the heap that there is additional metadata associated with the allocation. In previous versions of Windows, an attacker could corrupt the header of an allocation and make it appear as if the allocation had an extended block header. This could then be used by an attacker to force the heap to free another allocation that is currently in use by the program. The Windows 8 heap mitigates this attack by performing additional validation on extended block headers to ensure that they are correct. Blocks cannot be allocated if they are already busy Some of the attacks that have been proposed by security researchers rely on reallocating memory that is already in use by the program (e.g. [3]). This can allow an attacker to corrupt the state of an in-use heap allocation, such as a C++ object, and thereby gain control of the instruction pointer. The Windows 8 heap mitigates this attack by verifying that an allocation is not already flagged as in-use (“busy”) when it is about to be allocated. If a block is flagged as in-use, the heap takes steps to safely terminate the process. Encoded FirstAllocationOffset and BlockStride One of the exploitation techniques proposed in [4] involved corrupting heap metadata (FirstAllocationOffset and BlockStride) that is used by the Low Fragmentation Heap (LFH) to calculate the address of an allocation within a subsegment. By corrupting these fields, an attacker can trick the heap into returning an address that is outside the bounds of a subsegment and potentially enable corruption of other in-use heap allocations. The heap manager in Windows 8.1 addresses this attack by encoding the FirstAllocationOffset and BlockStride fields in order to limit an attacker’s ability to deterministically control the calculation of allocation addresses by the LFH. Guard pages One of the ways that the Windows 8 heap better protects application data and heap metadata is through the use of guard pages. In this context, a guard page is an inaccessible page of memory that will cause an access violation if an application attempts to read from it or write to it. Placing a guard page between certain types of sub-regions within the heap helps to partition the heap and localize any memory corruptions that may occur. In an ideal setting, the Windows heap would encapsulate all allocations in guard pages in a manner that is similar to full-page heap verification. Unfortunately, this type of protection is not feasible for performance reasons. Instead, the Windows 8 heap uses guard pages to isolate certain types of sub-regions within the heap. In particular, guard pages are enabled for the following types of sub-regions: Large allocations. In cases where an application attempts to allocate memory that is larger than 512K (on 32-bit) or 1MB (on 64-bit), the memory allocation request is passed directly to the virtual memory allocator and the size is updated to allocate extra space for a guard page. This ensures that all large allocations have a trailing guard page. Heap segments. The Windows heap allocates large chunks of memory, known as heap segments, which are divided up as an application allocates memory. The Windows 8 heap adds a trailing guard page to all heap segments when they are allocated. Maximally-sized subsegments. Each heap segment may contain one or more subsegment that is used by the frontend allocator (the Low Fragmentation Heap, or LFH) to allocate blocks of the same size. Once a certain threshold has been reached for allocating blocks of a given size, the LFH will begin allocating maximally-sized subsegments, which are subsegments that contain the maximum number of blocks possible for a given size. The Windows 8 heap adds a trailing guard page to maximally-sized subsegments. For 32-bit applications, guard pages are inserted probabilistically to minimize the amount of virtual address space that is consumed. Allocation order randomization One of the behaviors that attackers rely on when exploiting heap buffer overruns is that there must be a way to reliably position certain heap allocations adjacent to one another. This requirement stems from the fact that an attacker needs to know how many bytes must be written in order to corrupt a target allocation on the heap (while minimizing collateral damage to the heap that could cause the application and hence the attack to be terminated). Attackers typically try to ensure that allocations are immediately adjacent to each other through techniques that are often referred to as heap massaging or heap normalization. These techniques attempt to bring the heap into a state where new allocations are placed at a desired location with respect to one another. In Windows 8, a new security feature has been added to the LFH which randomizes the order of allocations. This means that allocations that are made through the LFH are no longer guaranteed to be placed immediately adjacent to one another even after an attacker has attempted to normalize the heap. This has the effect of preventing an attacker from reliably assuming that an allocation containing a target object will be positioned after the allocation that they are able to overflow. While an attacker may attempt to increase the reliability of their attack by corrupting more data or allocating more target objects, they run the risk of destabilizing the process by corrupting other heap state or causing the process to terminate by accessing a guard page as described in the previous section. This is a good example of several mitigations working together: neither is foolproof on its own, but combined they result in increasingly complex requirements for a successful attack. Although allocation order randomization helps make the internal layout of the heap nondeterministic, there are limitations to how far it goes. First and foremost, the performance of the Windows heap is critical as it is used as a general purpose memory allocator by the vast majority of the applications that run on Windows. As a side effect of this, allocation order randomization is currently limited to randomizing allocations within individual LFH subsegments (which accounts for the majority of allocations made by applications). This means backend allocations have no inherent entropy and therefore may be subject to deterministic allocation patterns, as noted in [5]. In addition to performance, there are also inherent limits to the effectiveness of allocation order randomization. If an attacker can read the contents of heap memory, they may be able to overcome the effects of randomization. Similarly, allocation order randomization is not designed to strongly mitigate heap vulnerabilities that are related to object lifetime issues, such as use after free vulnerabilities. This is because an attacker will generally be able to allocate a sufficient number of replacement objects to overcome the effects of allocation order randomization. We’ll discuss some other mitigations that are targeted at addressing use after free issues, which are increasingly preferred by exploit writers, later in this series. Conclusion The hardening changes that have been made to the Windows heap manager in Windows 8 and Windows 8.1 have been designed to make it more difficult and costly to exploit heap corruption vulnerabilities. This has been accomplished by adding additional integrity checks to metadata that is used by the heap, by protecting application data stored on the heap through the use of guard pages, and by randomizing the order of allocations. These mitigations do not make heap corruption vulnerabilities impossible to exploit, but they do have an impact on the time it takes to develop an exploit and how reliable an exploit will be. Both of these factors play a role in determining whether or not an attacker will develop an exploit for a vulnerability. With that being said, the fact that heap corruption vulnerabilities are the most common vulnerability class that we address through security updates means it is likely that we will continue to see additional research into new exploitation techniques for heap vulnerabilities in the future. As such, we will continue to look for ways to harden the Windows heap to further increase the difficulty of developing reliable exploits for heap corruption vulnerabilities. - Matt Miller References [1] Ben Hawkes. Attacking the Vista Heap. Black Hat USA. Aug, 2008. [2] Ben Hawkes. Attacking the Vista Heap. Ruxcon. Nov, 2008. [3] Chris Valasek. Modern Heap Exploitation using the Low Fragmentation Heap. SyScan Taipei. Nov, 2011. [4] Chris Valasek. Windows 8 Heap Internals. Black Hat USA. Aug, 2012. [5] Zhenhua Liu. Advanced Heap Manipulation in Windows 8. Black Hat Europe, Mar, 2013. Sursa: Software Defense: mitigating heap corruption vulnerabilities - Security Research & Defense - Site Home - TechNet Blogs PS: Matt Miller e "skape". Nu ma astept sa stiti cine e, dar poate va informati.

Proxy DDOSer? Adica sa iti dai DOS singur? Cat despre Facebook bot, vezi ca a facut Zatarra ceva misto.

Intrati si voi mai des pe forum.

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