A Complete Hacker's Handbook

View A Complete Hacker's Handbook flipbook.

The Hacker’s Handbook The Strategy behind Breaking into and Defending Networks

OTHER AUERBACH PUBLICATIONS The ABCs of IP Addressing Gilbert Held ISBN: 0-8493-1144-6 The ABCs of LDAP Reinhard Voglmaier ISBN: 0-8493-1346-5 The ABCs of TCP/IP Gilbert Held ISBN: 0-8493-1463-1 Building an Information Security Awareness Program Mark B. Desman ISBN: 0-8493-0116-5 Building a Wireless Office Gilbert Held ISBN: 0-8493-1271-X The Complete Book of Middleware Judith Myerson ISBN: 0-8493-1272-8 Computer Telephony Integration, 2nd Edition William A. Yarberry, Jr. ISBN: 0-8493-1438-0 Electronic Bill Presentment and Payment Kornel Terplan ISBN: 0-8493-1452-6 Information Security Architecture Jan Killmeyer Tudor ISBN: 0-8493-9988-2 Information Security Management Handbook, 4th Edition, Volume 1 Harold F. Tipton and Micki Krause, Editors ISBN: 0-8493-9829-0 Information Security Management Handbook, 4th Edition, Volume 2 Harold F. Tipton and Micki Krause, Editors ISBN: 0-8493-0800-3 Information Security Management Handbook, 4th Edition, Volume 3 Harold F. Tipton and Micki Krause, Editors ISBN: 0-8493-1127-6 Information Security Management Handbook, 4th Edition, Volume 4 Harold F. Tipton and Micki Krause, Editors ISBN: 0-8493-1518-2 Information Security Policies, Procedures, and Standards: Guidelines for Effective Information Security Management Thomas R. Peltier ISBN: 0-8493-1137-3 Information Security Risk Analysis Thomas R. Peltier ISBN: 0-8493-0880-1 Interpreting the CMMI: A Process Improvement Approach Margaret Kulpa and Kurt Johnson ISBN: 0-8493-1654-5 IS Management Handbook, 8th Edition Carol V. Brown and Heikki Topi ISBN: 0-8493-1595-6 Managing a Network Vulnerability Assessment Thomas R. Peltier and Justin Peltier ISBN: 0-8493-1270-1 A Practical Guide to Security Engineering and Information Assurance Debra Herrmann ISBN: 0-8493-1163-2 The Privacy Papers: Managing Technology and Consumers, Employee, and Legislative Action Rebecca Herold ISBN: 0-8493-1248-5 Securing and Controlling Cisco Routers Peter T. Davis ISBN: 0-8493-1290-6 Six Sigma Software Development Christine B. Tayntor ISBN: 0-8493-1193-4 Software Engineering Measurement John Munson ISBN: 0-8493-1502-6 A Technical Guide to IPSec Virtual Private Networks James S. Tiller ISBN: 0-8493-0876-3 Telecommunications Cost Management Brian DiMarsico, Thomas Phelps IV, and William A. Yarberry, Jr. ISBN: 0-8493-1101-2 AUERBACH PUBLICATIONS www.auerbach-publications.com To Order Call: 1-800-272-7737 • Fax: 1-800-374-3401 E-mail: orders@crcpress.com

Library of Congress Cataloging-in-Publication Data Young, Susan (Susan Elizabeth), 1968– The hacker’s handbook : the strategy behind breaking into and defending Networks / Susan Young, Dave Aitel. p. cm. Includes bibliographical references and index. ISBN 0-8493-0888-7 (alk. paper) 1. Computer networks—Security measures. 2. Computer networks—Access control. 3. Computer hackers. I. Aitel, Dave. II. Title. TK5105.59.Y68 2003 005.8—dc22 2003055391 CIP This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the authors and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microfilming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. All rights reserved. Authorization to photocopy items for internal or personal use, or the personal or internal use of specific clients, may be granted by CRC Press LLC, provided that $1.50 per page photocopied is paid directly to Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923 USA. The fee code for users of the Transactional Reporting Service is ISBN 0-8493-0888-7/04/$0.00+$1.50. The fee is subject to change without notice. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. The consent of CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. Specific permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation, without intent to infringe. Visit the Auerbach Publications Web site at www.auerbach-publications.com © 2004 by CRC Press LLC Auerbach is an imprint of CRC Press LLC No claim to original U.S. Government works International Standard Book Number 0-8493-0888-7 Library of Congress Card Number 2003055391 DOI: 10.1201/9780203490044

Acknowledgments Every book, as they say, has a story. This book’s history has been a long and varied one. Along the way, numerous individuals have contributed their time, focus, energy, technical acumen, or moral support to seeing The Hacker’s Handbook through to its conclusion. The authors would like to thank the following individuals for their con tributions and support: • Rich O’Hanley and the production staff at Auerbach Press for their tireless support of this book, in spite of its long (and somewhat nefarious) history. • Our contributing authors — Felix Lindner, Jim Barrett, Scott Brown, and John Zuena — for taking the time and care to write several excellent chapters on the hacking community, malware, directory services, and network hardware that contain some truly unique and interesting material. • Our technical reviewers, including Jim Tiller, Anton Chuvakin, Sean Cemm, Ben Rothke, and Ted Shagory, for their insights and for dedicating their time and energy to helping to shape a better book. We are confident that this review process will continue as this text goes to publication, and want — in advance — to thank our readers and reviewers for their attention to the ongoing quality of this book. In addition, Dave Aitel would like to thank Justine Bone for her support and encouragement and Susan Young would like to thank the following indi viduals: the Darklord (Thomas McGinn) for keeping his personal commit ment to support the effort that went into this book in spite of many months of spent deadlines, missed weekends, and fatigue (thanks, T2B); Trevor Young, for lending his genuine talent, enthusiasm, time, and care to crafting the illustrations throughout this book; Gemma Young, and her parents, Sylvia and Neil, for their interest, support, and advice through two years of long distance phone calls; and International Network Services (and parti cularly Steven Marandola, Bob Breingan, and Shaun Meaney) for making available time and support for the completion of this book. v

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Authors Dave Aitel is the founder of Immunity, Inc. (www.immunitysec.com), with prior experience at both private industry security consulting companies and the National Security Agency. His tools, SPIKE and SPIKE Proxy, are widely regarded as the best black box application assessment tools available. Susan Young has worked in the security field for the past seven years, four of which have been spent in the security consulting arena, helping clients design and implement secure networks, training on security technologies, and conducting security assessments and penetration tests of client system or network defenses (so-called ethical hacking). Her experience has included consulting work in the defense sector and the financial industry, as well as time spent evaluating and deconstructing various security products. She currently works as a senior security consultant in the Boston area secu rity practice of International Network Services (INS). vi

Contributors Jim Barrett (CISA, CISSP, MCSE, CCNP) is a principal consultant for the Boston office of International Network Services (INS). He currently serves as the national Microsoft practice leader for INS and has been working with Microsoft technologies for longer than he can remember. Prior to INS, Jim spent several years as a member of the information systems audit and security practice of Ernst & Young LLP, where he co-authored the firm’s audit methodology for Novell NetWare 4.1 and was an instructor at the Ernst & Young National Education Center. His areas of expertise include network operating systems and information systems security. Scott Brown (CISSP, GCIA, GCIH) is a senior security consultant for Interna tional Network Services, with more than 13 years experience in the infor mation technologies field. He is a Certified Information Systems Security Professional (CISSP), and holds both SANS GCIA and GCIH certifications. Scott is also a private pilot with a rating in single engine aircraft. John Zuena (CISSP, CCNA, CCDA, NNCSE) is a senior consultant for Inter national Network Services, with more than 14 years experience in the infor mation technologies field. He is a Certified Information Systems Security Professional (CISSP) and holds both Cisco and Nortel internetworking cer tifications. He is also a private pilot with ratings in both single engine air planes and helicopters. vii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Illustrator Trevor Young has been drawing, painting, creating, and generally exercis ing his artistic imagination for a very long time. Young attended Camberwell College of Art in London, studying graphic design and illustration, and has gone on to a successful career in the film special effects industry in London, first working for the Film Factory and currently as a digital compositor for Hypnosis VFX Ltd. You will find him in the IMDb at http://us.imdb.com/Name?Young,+Trevor. He has continued to work in illustration from time to time and generously contributed his time to create a set of illustrations for this book that have become truly integral to the book and the subject matter. viii

List of Abbreviations ACK Acknowledge ARIN American Registry for Internet Numbers ASCII ASCII Character Set (ASCII) ASN Autonomous System Number ASP Active Server Pages or Application Service Provider BSDI Berkeley Software Design (BSD) Operating System Internet Server Edition CANVAS Immunity Security’s CANVAS Vulnerability Scanner CAST Computer Aided Software Testing CDE Common Desktop Environment CHAM Common Hacking Attack Methods CIFS Common Internet File Sharing CPAN Comprehensive Perl Archive Network CRC Cyclic Redundancy Check CVE Common Vulnerabilities and Exposures (List) CVS Concurrent Versions System Source Code Control System DDoS Distributed Denial-of-Service DID Direct Inward Dialing DIT Directory Information Tree DNS Domain Name System DNSSEC Domain Name System Security DoS Denial-of-Service DSA Digital Signature Algorithm EFS Encrypting File System (Microsoft) EIGRP Enhanced Interior Gateway Routing Protocol EIP Extended Instruction Pointer ESMTP Extended Simple Mail Transfer (Protocol) EVT Event (Microsoft) FIFO First In First Out is an approach to handling queue or stack requests where the oldest requests are prioritized FX Handle for Felix Lindner GCC GNU C Compiler GCIA GIAC Certified Intrusion Analyst GCIH GIAC Certified Incident Handler ix

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS GDB GNU Project Debugger GID Group ID (Access Control Lists) GINA Graphical Identification and Authentication (Dynamic Link Library, Microsoft) GNOME GNU Free Desktop Environment GNU GNU Software Foundation HIDS Host Intrusion Detection System HKEY Microsoft Registry Key Designation (Hive Key) HMAC Keyed Hashing Message Authentication HQ Headquarters HTTPS Secure Hypertext Transmission Protocol HUMINT Human Intelligence ICQ ICQ Protocol IDS Intrusion Detection System IKE Internet Key Exchange (Protocol) IMDb Internet Movie Database IPO Initial Public Offering IPSec IP Security (Protocol) IRIX Silicon Graphics IRIX Operating System (IRIX) ISAKMP Internet Security Association and Key Management Protocol ISS Internet Security Systems IUSR Internet User (i.e., IUSR_name) is an anonymous user desig nation used by Microsoft’s Internet Information Server (IIS) KB Kilobytes or Knowledgebase KDE K Desktop Environment KSL Keystroke Logger LKM Loadable Kernel Modules LM Lan Manager (Microsoft Authentication Service) LT2P Layer 2 Tunneling Protocol MIB Management Information Base MSDE Microsoft Data Engine MSDN Microsoft Developer Network MSRPC Microsoft Remote Procedure Call MUA Mail User Agent MVS Multiple Virtual Storage (MVS) Operating System MX Mail Exchange (Record, DNS) NASL Nessus Attack Scripting Language (Nessus Security Scanner) NIDS Network Intrusion Detection System NMAP Network Mapper (Nmap) NMS Network Management Station NTFS NT File System NTFS5 NT File System 5 NTLM NT LanMan (Authentication) OU Organizational Unit PCX .pcx files created with MS Paintbrush tool x

List of Abbreviations PHP Hypertext Preprocessor PID Process Identifier PUT PUT (FTP) RCS Revision Control System RDS Remote Data Service RIP Routing Information Protocol RSA RSA Security, Inc. SAM Security Accounts Manager (Microsoft) SANS Sysadmin, Audit, Network, Security (SANS Institute) SASL Simple Authentication and Security Layer SATAN Security Administrator Tool for Analyzing Networks SID Security Identifier (Microsoft) SIGINT Signal Intelligence SMB Server Message Block (Protocol) SOCKS Sockets Protocol (Firewall) SRV Service Record (DNS) SUID Set User ID (bit) utilized in UNIX Operating Systems to impose File System Access Control Lists SYN Synchronize (TCP SYN) SYN-ACK Synchronize-Acknowledge (TCP SYN ACK) USB Universal Serial Bus VB Visual Basic VM Virtual Machine VMS VMS (Operating System) VNC AT&T Virtual Network Computing (Software) XDMCPD X Display Manager Control Protocol XOR Exclusive OR xi

Contents 1 Introduction: The Chess Game . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Book Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Chapter 2. Case Study in Subversion. . . . . . . . . . . . . . . . . . . . 4 Chapter 3. Know Your Opponent . . . . . . . . . . . . . . . . . . . . . . . 5 Chapter 4. Anatomy of an Attack . . . . . . . . . . . . . . . . . . . . . . . 5 Chapter 5. Your Defensive Arsenal . . . . . . . . . . . . . . . . . . . . . 6 Chapter 6. Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Chapter 7. IP and Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . 7 Chapter 8. The Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Chapter 9. Domain Name System (DNS) . . . . . . . . . . . . . . . . . 7 Chapter 10. Directory Services. . . . . . . . . . . . . . . . . . . . . . . . . 8 Chapter 11. Simple Mail Transfer Protocol (SMTP). . . . . . . . 8 Chapter 12. Hypertext Transfer Protocol (HTTP) . . . . . . . . . 9 Chapter 13. Database Hacking . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 14. Malware and Viruses . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 15. Network Hardware . . . . . . . . . . . . . . . . . . . . . . . 10 Chapter 16. Consolidating Gains . . . . . . . . . . . . . . . . . . . . . . 10 Chapter 17. After the Fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 18. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 PART I FOUNDATION MATERIAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 Case Study in Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Dalmedica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 The Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 The Investigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3 Know Your Opponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Script Kiddy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Cracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 White Hat Hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Black Hat Hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Hacktivism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Professional Attackers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 xiii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Computer Industry and Campus . . . . . . . . . . . . . . . . . . . . . . 37 System Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Home Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Home Computers: Commercial Software . . . . . . . . . . . . . . . 40 Home Computers: The BBS . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Phone Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Ethics and Full Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Opponents Inside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 The Hostile Insider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Corporate Politics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4 Anatomy of an Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Social Engineering and Site Reconnaissance . . . . . . . . . . . . . . . . 59 Internet Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Internet Search Engines and Usenet Tools . . . . . . . . . . . . . . 62 Financial Search Tools, Directories, Yellow Pages, and Other Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 IP and Network Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Registrar and whois Searches. . . . . . . . . . . . . . . . . . . . . . . . . 65 Network Registrar Searches (ARIN) . . . . . . . . . . . . . . . . . . . . 66 DNS Reconnaissance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Mapping Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 War Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Network Mapping (ICMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 ICMP Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 TCP Pings: An Alternative to ICMP. . . . . . . . . . . . . . . . . . . . . 76 Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Additional Network Mapping Tools . . . . . . . . . . . . . . . . . . . . 78 Port Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 TCP and UDP Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Banner Grabbing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Packet Fragmentation Options . . . . . . . . . . . . . . . . . . . . . . . . 81 Decoy Scanning Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Ident Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 FTP Bounce Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Source Port Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Stack Fingerprinting Techniques . . . . . . . . . . . . . . . . . . . . . . 83 Vulnerability Scanning (Network-Based OS and Application Interrogation) . . . . . . . . . . . . . . . . . . . . . . . . 84 Researching and Probing Vulnerabilities . . . . . . . . . . . . . . . . . . . 88 System/Network Penetration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 xiv

Contents Account (Password) Cracking . . . . . . . . . . . . . . . . . . . . . . . . 89 Application Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Cache Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 File System Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Hostile and Self-Replicating Code . . . . . . . . . . . . . . . . . . . . . 91 Programming Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Process Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Shell Hacking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 State-Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Traffic Capture (Sniffing). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Trust Relationship Exploitation . . . . . . . . . . . . . . . . . . . . . . . 95 Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Consolidation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Web References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5 Your Defensive Arsenal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 The Defensive Arsenal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Network Access Controls (Firewalls) . . . . . . . . . . . . . . 104 State Management Attacks on Firewalls. . . . . . . . . . . . 110 Firewall Ruleset and Packet Filter Reconnaissance . . 112 IP Spoofing to Circumvent Network Access Controls . 113 Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Packet Fragmentation Attacks. . . . . . . . . . . . . . . . . . . . 116 Application Level Attacks . . . . . . . . . . . . . . . . . . . . . . . 117 System Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Host-Based Firewalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Operating System Access Controls and Privilege Management . . . . . . . . . . . . . . . . . . . 118 Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 IP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Password Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Account/Password Cracking . . . . . . . . . . . . . . . . . . . . . 121 Eavesdropping Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Password Guessing Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 126 Token-Based Authentication. . . . . . . . . . . . . . . . . . . . . . . . . 126 Session Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Session Authentication Scheme Cracking . . . . . . . . . . 127 Generation of Counterfeit Session Auth Credentials . . 128 Session ID Brute-Forcing . . . . . . . . . . . . . . . . . . . . . . . . 129 xv

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Session Auth Eavesdropping . . . . . . . . . . . . . . . . . . . . . 131 Key Management Vulnerabilities Dictionary and Brute-Force Attacks Session Auth/ID Stealing or “Hijacking” . . . . . . . . . . . . 132 Client Session/ID Theft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Cryptographic (Key-Based) Authentication . . . . . . . . . . . . 133 Key Transfer and Key Management Vulnerabilities . . . . . . 139 Key Transfer Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . 139 (Public Key Infrastructure) . . . . . . . . . . . . . . . . . . . 139 Key Binding and Impersonation Vulnerabilities. . . . . . . . . 143 against Weak Secrets. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Centralized Authentication Servers . . . . . . . . . . . . . . . . . . . 143 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 TACACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Human Authentication (Biometrics) . . . . . . . . . . . . . . . . . . 150 Resource Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Nonrepudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Digital Signatures (and Digital Certificates) . . . . . . . . . . . . 155 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . . . . . 159 Session and Protocol Encryption . . . . . . . . . . . . . . . . . . . . . 165 Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . 165 Certificate and Impersonation Attacks (SSL). . . . . . . . 167 Cryptographic Weaknesses (SSL) . . . . . . . . . . . . . . . . . 168 Attacks against the Handshake Protocol (SSL) . . . . . . 169 SSL Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . 169 Man-in-the-Middle Attack Version Rollback (SSL) . . . . 170 Viruses, Worms, and other Application Issues (SSL) . . 170 Secure Shell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 File System Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Network-Based and Host-Based IDS. . . . . . . . . . . . . . . . . . . 174 Anomaly-Based (Behavior-Based) IDS . . . . . . . . . . . . . . . . . 174 Signature-Based (Knowledge-Based) IDS. . . . . . . . . . . . . . . 177 IDS Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Address Spoofing or Proxying . . . . . . . . . . . . . . . . . . . . 178 Attacking the IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Instigating Active Events . . . . . . . . . . . . . . . . . . . . . . . . 179 Nondefault Evasion and Pattern Change Evasion . . . . 179 Packet Fragmentation and “Session Splicing” . . . . . . . 179 Port Scan Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 TCP Session Synchronization Attacks . . . . . . . . . . . . . 180 xvi

6 Contents URL Encoding (Unicode and Hex Attacks). . . . . . . . . . 180 Web Evasion Techniques . . . . . . . . . . . . . . . . . . . . . . . . 181 File System Integrity Checkers . . . . . . . . . . . . . . . . . . . . . . . 181 Security Information Management. . . . . . . . . . . . . . . . . . . . 182 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Application Proxies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Content Assurance (Antivirus, Content Scanning) . . . 183 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Web References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Bytecode/Just in Time Compiled Code Interpreted (Usually Compiled into Byte Codes at Runtime): Perl, Python (Scripting Languages), Language-Specific Flaws and Strategic Ways to Protect The Basics of Buffer Overflows and Other Memory Languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Speed and Security Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Native Compiled Code: C/C++/Assembly . . . . . . . . . . . . . . 191 (“Managed” Code): C#/Java . . . . . . . . . . . . . . . . . . . . . . 191 PHP, Visual Basic, .ASP, Lisp, JSP (Web Languages) . . 192 against Them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Allocation Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Basic Stack Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Options for the Hacker after a Stack Overflow. . . . . . . . . . 198 So What Is a Stack Canary? . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Heap Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Format String Bugs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Integer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Signal Races on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 What Is Shellcode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Interpreter Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 File Name Canonicalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Logic Error War Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Platform-Specific Programming Security Issues . . . . . . . . . . . . 207 Windows NT Compared to UNIX . . . . . . . . . . . . . . . . . . . . . 207 Types of Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Cross-Site Scripting Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . 210 Java J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Traditional ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 xvii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS .Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 LAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Remote Procedure Calling. . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Creating an RPC Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Special Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Setuid Applications on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . 214 DCOM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Auditing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Tools That Aid Source Auditing . . . . . . . . . . . . . . . . . . . . . . 216 Tools That Aid Reverse Engineering . . . . . . . . . . . . . . . . . . 219 Fuzzing Audit Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Web Security Audit Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 General Security Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Encryption and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Layered Defenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Platform-Specific Defenses (Security through Security and Security through Obscurity) . . . . . . . . . . . . . . . . . . . . . 224 Nonexecutable Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Using a Different Platform Than Expected . . . . . . . . . . . . . 225 File System User Access Controls . . . . . . . . . . . . . . . . . . . . 226 Process Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 The Insider Problem, Backdoors, and Logic Bombs. . . . . . . . . 226 Buying an Application Assessment. . . . . . . . . . . . . . . . . . . . . . . 227 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 7 IP and Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Layer 2 Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Address Resolution Protocol (ARP). . . . . . . . . . . . . . . . . . . 231 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Security (Mapping ARP Exploits to ARP Defenses). . . 235 Static ARP Entries on Internet Gateways and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Network Management . . . . . . . . . . . . . . . . . . . . . . . 236 ARP Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Port-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Reverse Address Resolution Protocol (RARP) . . . . . . . . . . 237 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Security (Defenses for RARP-Related Attacks: DHCP, BOOTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Assignment of Static IP Addresses to Clients . . . . . . . 238 Use of DHCP/BOOTP MAC Controls . . . . . . . . . . . . . . . 238 ARP Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 xviii

Contents Port-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Layer 3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 IP Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 IP Eavesdropping (Packet Sniffing) . . . . . . . . . . . . 241 IP Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 IP Session Hijacking (Man-in-the-Middle Attacks) . . 250 IP Packet Fragmentation Attacks . . . . . . . . . . . . . . 254 ICMP-Based Fragmentation Attacks . . . . . . . . 256 Tiny Fragment Attacks . . . . . . . . . . . . . . . . . . . 257 Overlapping Fragment Attacks . . . . . . . . . . . . 258 IP Covert Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 260 Security (Mapping IP Exploits to IP Defenses) . . . . . . 260 Tools and Techniques to Detect Promiscuous Mode Packet Sniffers. . . . . . . . . . . . . . . . . . . . . 261 System Audits to Identify NICs in Promiscuous Mode . . . . . . . . . . . . . . . . . . . . 262 System Hardening Procedures to Inhibit Sniffer Installation . . . . . . . . . . . . . . 262 Inspection of Systems for Signs of Rootkit Compromise. . . . . . . . . . . . . . . . . . . 262 Institution of Switched Network. . . . . . . . . . . . . . . 262 Institution of ARP Monitoring . . . . . . . . . . . . . . . . . 263 Institution of Traffic Encryption. . . . . . . . . . . . . . . 263 Implementation of Strong Authentication. . . . . . . 264 Institution of Spoof Protection at Firewalls and Access Control Devices. . . . . . . . . . . . . . . 265 Patch TCP/IP Implementations. . . . . . . . . . . . . . . . 265 Deny Source Routing at Gateways and Firewalls . . 266 Deny ICMP Redirects at Gateways and Firewalls. . 266 Deter the Use of IP Addresses for Authentication or Construction of Trust Relationships . . . . . 266 Implement ARP Controls . . . . . . . . . . . . . . . . . . . . . 266 Monitor Network Traffic Using Network and Host-based IDS . . . . . . . . . . . . . . . . . . . . . . 266 Restrict ICMP Traffic into and out of a Protected Network . . . . . . . . . . . . . . . . . . . . . 267 Patch Firewalls and Intrusion Detection Systems against Packet Fragmentation Attacks . . . . . . 267 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 268 White Papers and Web References . . . . . . . . . . . . . . . . . . . 268 xix

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS 8 The Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Layer 3 Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . 272 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 ICMP-Based Denial-of-Service . . . . . . . . . . . . . . . . . 273 ICMP Network Reconnaissance . . . . . . . . . . . . . . . 279 ICMP Time Exceeded . . . . . . . . . . . . . . . . . . . . . . . . 281 ICMP Access Control Enumeration . . . . . . . . . . . . 282 ICMP Stack Fingerprinting . . . . . . . . . . . . . . . . . . . . 284 ICMP Covert Tunneling . . . . . . . . . . . . . . . . . . . . . . 285 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Deny ICMP Broadcasts. . . . . . . . . . . . . . . . . . . . . . . 285 Network Controls against ICMP Packet Flooding. . 286 IP Spoofing Defenses . . . . . . . . . . . . . . . . . . . . . . . . 287 Patch TCP/IP Implementations against ICMP Denial-of-Service and ICMP Typing . . . . 287 Monitor Network Traffic Using Network and Host-Based Intrusion Detection Systems (IDSs). 287 Restriction of Specific ICMP Message Types. . . . . 288 Monitor ICMP Activity at Firewalls and Intrusion Detection Systems. . . . . . . . . . . 288 Layer 4 Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . 288 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Covert TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 TCP Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . 294 TCP Sequence Number Prediction (TCP Spoofing and Session Hijacking) . . . . . . 296 TCP Stack Fingerprinting . . . . . . . . . . . . . . . . . . . . . 297 TCP State-Based Attacks . . . . . . . . . . . . . . . . . . . . . 298 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Network Controls against TCP Packet Flooding . . 301 IP Spoofing Defenses . . . . . . . . . . . . . . . . . . . . . . . . 302 Patch TCP/IP Implementations against TCP Denial-of-Service, TCP Stack Fingerprinting, and TCP Sequence Number Prediction. . . . . . 302 Monitor Network Traffic Using Network and Host-Based IDS Systems . . . . . . . . . . . . . . 302 Activation of SYN Flood Protection on Firewalls and Perimeter Gateways. . . . . . . . . . . . . . . . . . 302 Implement Stateful Firewalling . . . . . . . . . . . . . . . . 303 User Datagram Protocol (UDP). . . . . . . . . . . . . . . . . . . . . . . 303 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 xx

Contents Hacking Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Covert UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 UDP Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . 304 UDP Packet Inspection Vulnerabilities . . . . . . . . . 306 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Disable Unnecessary UDP Services . . . . . . . . . . . . 306 Network Controls against UDP Packet Flooding . 307 IP Spoofing Defenses . . . . . . . . . . . . . . . . . . . . . . . . 308 Patch TCP/IP Implementations against UDP Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . 308 Monitor Network Traffic Using Network- and Host-Based IDS Systems . . . . . . . . . . . . . . 308 Implement Stateful Firewalling . . . . . . . . . . . . . . . . 308 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 309 White Papers and Web References . . . . . . . . . . . . . . . . . . . 309 PART II SYSTEM AND NETWORK PENETRATION . . . . . . . . . . . . . . . 311 9 Domain Name System (DNS). . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 The DNS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 DNS Protocol and Packet Constructs (Packet Data Hacking) . . . . . . . . . . . . . . . . . . . . . . . . . . 314 DNS Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 DNS Exploits and DNS Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Protocol-Based Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 DNS Registration Information . . . . . . . . . . . . . . . . . 322 Name Server Information . . . . . . . . . . . . . . . . . . . . 322 IP Address and Network Topology Data . . . . . . . . 322 Information on Key Application Servers . . . . . . . . 323 Protocol-Based Denial-of-Service . . . . . . . . . . . . . . . . . 325 Dynamic DNS (DDNS) Hacking . . . . . . . . . . . . . . . . . . . 328 Application-Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Buffer Overflows (Privileged Server Access, Denial-of-Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Exploiting the DNS Trust Model . . . . . . . . . . . . . . . . . . 331 DNS Registration Attacks . . . . . . . . . . . . . . . . . . . . 331 DNS Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Cache Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 DNS Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 DNS Security and Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Mapping Exploits to Defenses . . . . . . . . . . . . . . . . . . . . . . . 336 Defensive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 xxi

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Configuration Audit and Verification Tools . . . . . . . . . 338 DDNS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Name Server Redundancy . . . . . . . . . . . . . . . . . . . . . . . 340 DNSSEC: Authentication and Encryption of DNS Data. . 340 Name Server Software Upgrade(s) . . . . . . . . . . . . . . . . 343 Network and Name Server Monitoring and Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . 343 Berkeley Internet Name Daemon (BIND) Logging Controls . . . . . . . . . . . . . . . . . . . . . . . . 343 Microsoft Windows 2000 DNS Logging Controls. . . . . . . . . 344 Patches and Service Packs . . . . . . . . . . . . . . . . . . . . . . . 345 Server-Side Access Controls . . . . . . . . . . . . . . . . . . . . . 345 Split-Level DNS Topologies (and DNS Proxying) . . . . . . . . 345 Split-Level DNS Topology . . . . . . . . . . . . . . . . . . . . . . . . 347 System and Service Hardening . . . . . . . . . . . . . . . . . . . 347 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 350 Mailing Lists and Newsgroups . . . . . . . . . . . . . . . . . . . . . . . 350 Web References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 10 Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 What Is a Directory Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Components of a Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Leaf Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Container Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Directory Information Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Directory Information Base (DIB). . . . . . . . . . . . . . . . . . . . . 353 Directory Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Directory Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Single Sign On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Uses for Directory Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Directory-Enabled Networking . . . . . . . . . . . . . . . . . . . . . . . 355 Linked Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Global Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Directory Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Physical vs. Logical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Flat vs. Hierarchical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 X.500 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 X.500 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 X.500 Partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 X.500 Objects and Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . 362 xxii

Contents A Word about Aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 X.500 Back-End Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Directory Information Tree . . . . . . . . . . . . . . . . . . . . . . 364 Directory Information Base . . . . . . . . . . . . . . . . . . . . . . 364 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Agents and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 X.500 Directory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 X.500 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Simple Authentication . . . . . . . . . . . . . . . . . . . . . . . 367 Strong Authentication . . . . . . . . . . . . . . . . . . . . . . . 368 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Lightweight Directory Access Protocol (LDAP) . . . . . . . . . . . . 370 LDAP Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 LDAP Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 LDAP Objects and Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 374 LDAP Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 LDAP Data Interchange Format (LDIF) . . . . . . . . . . . . . . . . 377 LDAP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Anonymous Access . . . . . . . . . . . . . . . . . . . . . . . . . 377 Simple Authentication . . . . . . . . . . . . . . . . . . . . . . . 377 Simple Authentication with Secure Sockets Layer (SSL)/Transport Layer Security (TLS) . . 378 Simple Authentication and Security Layer (SASL) . 378 Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 Windows 2000 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Windows 2000 Partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Windows 2000 Objects and Naming. . . . . . . . . . . . . . . . . . . 382 The Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 The Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 The Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 The Forest Root Domain. . . . . . . . . . . . . . . . . . . . . . . . . 384 Naming Standards and Resolution in Windows 2000 . . . . 384 Active Directory Back-End Processes . . . . . . . . . . . . . . . . . 387 The Directory Information Base (DIB) . . . . . . . . . . . . . 387 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 The Global Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Windows 2000 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 xxiii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 NTLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Exploiting LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Sun ONE Directory Server 5.1 . . . . . . . . . . . . . . . . . . . . . . . . 395 Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 11 Simple Mail Transfer Protocol (SMTP) . . . . . . . . . . . . . . . . . . . 411 The SMTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 SMTP Protocol and Packet Constructs (Packet Data Hacking). . . . . . . . . . . . . . . . . . . . . . . . . . . 412 SMTP Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 SMTP Protocol Commands and Protocol Extensions . . . . 417 Protocol Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 SMTP Exploits and SMTP Hacking . . . . . . . . . . . . . . . . . . . . . . . 419 SMTP Protocol Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Account Cracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Eavesdropping and Reconnaissance. . . . . . . . . . . . . . . 428 ESMTP and Command Set Vulnerabilities. . . . . . . . . . . . . . 432 Protocol-Based Denial-of-Service. . . . . . . . . . . . . . . . . . 432 Mail Bombing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Mail Spamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . . . . . 436 Application-Based Attacks . . . . . . . . . . . . . . . . . . . . . . . 436 Malicious Content (MIME Attacks). . . . . . . . . . . . . 436 Buffer Overflows (Privileged Server Access) . . . . 441 Worms and Automated Attack Tools . . . . . . . . . . . . . . . . . . 442 Application-Based Denial-of-Service . . . . . . . . . . . . . . . . . . 444 Attacks on the Mail Trust Model . . . . . . . . . . . . . . . . . . . . . 446 Mail Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Identity Impersonation . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Attacks on Data Integrity. . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Delivery Status Notification Manipulation . . . . . . . . . . . . . 449 SMTP Security and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 Mapping Exploits to Defenses. . . . . . . . . . . . . . . . . . . . . . . . 450 Defensive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 Antispam/Antirelay Controls . . . . . . . . . . . . . . . . . . . . . 450 Antivirus and Content Scanning . . . . . . . . . . . . . . . . . . 454 Client-Side Access Controls . . . . . . . . . . . . . . . . . . . . . . 454 Content or Code Signing . . . . . . . . . . . . . . . . . . . . . . . . . 455 Delivery Status Notification Controls . . . . . . . . . . . . . . 455 Disable Vulnerable ESMTP and SMTP Commands . . . 456 xxiv

Contents Disable Vulnerable MIME Types . . . . . . . . . . . . . . . . . . 456 Network and SMTP Server Monitoring, Transport Layer Security, Secure Socket Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . 456 Patches and Service Packs. . . . . . . . . . . . . . . . . . . . . . . 457 Separation of SMTP and Intranet Account Databases. . 457 Server-Side Access Controls . . . . . . . . . . . . . . . . . . . . . 458 Server Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 SMTP Header Stripping and Parsing. . . . . . . . . . . . . . . 458 SMTP Source Routing Controls . . . . . . . . . . . . . . . . . . . 458 Split SMTP Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 System and Service Hardening . . . . . . . . . . . . . . . . . . . 458 Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 461 White Papers and Web References . . . . . . . . . . . . . . . . . . . 462 12 Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . 463 HTTP Protocol and Packet Constructs Unauthorized Retrieval of Cache Data Buffer Overflows (Privileged Server Access, The HTTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 (Packet Data Hacking) . . . . . . . . . . . . . . . . . . . . . . . . . . 464 HTTP Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 HTTP Protocol Methods (and Associated Vulnerabilities) . 466 HTTP Exploits and HTTP Hacking . . . . . . . . . . . . . . . . . . . . . . . 468 HTTP Protocol Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Eavesdropping and Reconnaissance . . . . . . . . . . . . . . 469 Account Cracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 Basic Access Authentication . . . . . . . . . . . . . . . . . . . . . 477 Digest Access Authentication . . . . . . . . . . . . . . . . . . . . 477 HTTP Method Vulnerabilities . . . . . . . . . . . . . . . . . . . . 478 Content Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . . . . 478 Caching Exploits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 Cache Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . . . . . 480 and Cache Monitoring . . . . . . . . . . . . . . . . . . . . . . . 480 Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 Protocol-Based Denial-of-Service . . . . . . . . . . . . . . . . . 481 Application-Based Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Denial-of-Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Directory Traversal Attacks. . . . . . . . . . . . . . . . . . . . . . 484 Application-Based Denial-of-Service . . . . . . . . . . . . . . . 487 Attacks on the HTTP Trust Model . . . . . . . . . . . . . . . . . . . . 488 xxv

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS State-Based Attacks (Session ID Hacking) . . . . . . . . . . 488 HTTP Spoofing/HTTP Redirection. . . . . . . . . . . . . . . . . 491 Man-in-the-Middle Attacks (Session Hijacking) . . . . . . 492 HTTP Security and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 Mapping Exploits to Defenses. . . . . . . . . . . . . . . . . . . . . . . . 493 Defensive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Caching Controls and Cache Redundancy . . . . . . . . . . 493 Disable Vulnerable HTTP Methods . . . . . . . . . . . . . . . . 494 HTTP Header Stripping. . . . . . . . . . . . . . . . . . . . . . . . . . 494 Implementation of HTTP Digest Access Authentication . . . . . . . . . . . . . . . . . . . . . . . 494 Load Balancing and Server Redundancy . . . . . . . . . . . 497 Network and HTTP Server Monitoring, Intrusion Detection. . . . . . . . . . . . . . . . . . . . . . . . . . 497 Patches and Service Packs . . . . . . . . . . . . . . . . . . . . . . . 499 Security for Financial Transactions. . . . . . . . . . . . . . . . 499 Server-Side Access Controls . . . . . . . . . . . . . . . . . . . . . 500 System and Service Hardening . . . . . . . . . . . . . . . . . . . 500 Transport Layer Security or Secure Socket Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 502 Web References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 13 Database Hacking and Security . . . . . . . . . . . . . . . . . . . . . . . . . 503 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Enumeration of Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Phases of SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Hacking Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Overflows in Microsoft SQL Server . . . . . . . . . . . . . . . . . . . 507 You Had Me at Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 SQL Server Resolver Service Stack Overflow . . . . . . . 508 Microsoft SQL Server Postauth Vulnerabilities . . . . . . . . . 509 Microsoft SQL Server SQL Injection. . . . . . . . . . . . . . . . . . . 509 A Note on Attacking Cold Fusion Web Applications . . . . . 510 Default Accounts and Configurations . . . . . . . . . . . . . . . . . 510 Hacking Oracle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 Buffer Overflows in Oracle Servers . . . . . . . . . . . . . . . . . . . 512 SQL Injection on Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Default User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 Tools and Services for Oracle Assessments . . . . . . . . . . . . 514 Other Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 xxvi

Contents Connecting Backwards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 Demonstration and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 Phase 1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Phase 2. Reverse Engineering the Vulnerable Application. . 520 Phase 3. Getting the Results of Arbitrary Queries . . . . . . . 524 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 14 Malware and Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529 Ethics Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 Target Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 Script Malware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 Learning Script Virus Basics with Anna Kournikova . . . . . 534 Binary Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534 Binary File Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 Binary Boot Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 Hybrids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 Binary Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 Worst to Come . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 Adware Infections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 15 Network Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551 Network Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 Load-Balancing Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 Remote Access Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 Wireless Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554 Network Infrastructure Exploits and Hacking . . . . . . . . . . . . . . 554 Device Policy Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 Installation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556 Configuration Storage Policy . . . . . . . . . . . . . . . . . . . . . 556 Patch or Update Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 557 Denial-of-Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 Device Obliteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 Configuration Removal or Modification . . . . . . . . . . . . 557 Sending Crafted Requests . . . . . . . . . . . . . . . . . . . . . . . 558 Physical Device Theft . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 Environmental Control Modification . . . . . . . . . . . . . . 558 Resource Expenditure. . . . . . . . . . . . . . . . . . . . . . . . . . . 559 Diagnostic Port Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 559 Sequence (SYN) Attack. . . . . . . . . . . . . . . . . . . . . . . . . . 559 xxvii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Land Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 Bandwidth Expenditure . . . . . . . . . . . . . . . . . . . . . . . . . 560 Broadcast (Smurf) Attacks . . . . . . . . . . . . . . . . . . . . . . . 560 Other ICMP-Related Attacks. . . . . . . . . . . . . . . . . . . . . . 560 Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 ICMP Router Discovery Protocol (IDRP) Attack. . 561 Ping O’Death . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 Squelch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 Fragmented ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 Network Mapping Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . 562 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Broadcast Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Information Theft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 Network Sniffing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Hijacking Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565 Address Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565 TCP Sequence Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 565 Media Access (MAC) Address Exploits. . . . . . . . . . . . . 565 Password or Configuration Exploits . . . . . . . . . . . . . . . . . . 566 Default Passwords or Configurations . . . . . . . . . . . . . . 567 No Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 Weak Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567 Dictionary Password Attacks . . . . . . . . . . . . . . . . . 567 Brute-Force Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 568 Logging Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568 Log Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Log Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Log Rerouting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 Spoofed Event Management. . . . . . . . . . . . . . . . . . . . . . 570 Network Ports and Protocols Exploits and Attacks. . . . . . 570 Telnet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 Finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 Small Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 Device Management Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 572 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 Console Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 Modem Access (AUX) . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 Management Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 Web (HTTP[S]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 Telnet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573 SSH (Version 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 xxviii

Contents SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 Device Configuration Security Attacks . . . . . . . . . . . . . . . . 575 Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 Remote Loading (Network Loads) . . . . . . . . . . . . . . . . 576 Router-Specific Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576 Routing Protocol Attacks . . . . . . . . . . . . . . . . . . . . . . . . 576 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 IRDP Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Cisco Discovery Protocol (CDP) . . . . . . . . . . . . . . . . . . 577 Classless Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Source Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 Route Table Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 ARP Table Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 Man-in-the-Middle Attack . . . . . . . . . . . . . . . . . . . . 580 Access-Control Lists Attacks . . . . . . . . . . . . . . . . . . . . . . . . 580 Switch-Specific Exploits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580 ARP Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581 Man-in-the-Middle Attack . . . . . . . . . . . . . . . . . . . . 581 Media Access (MAC) Address Exploits . . . . . . . . . . . . . . . . 581 Changing a Host’s MAC. . . . . . . . . . . . . . . . . . . . . . . . . . 582 Duplicate MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . 582 Load-Balancing Device — Specific Exploits . . . . . . . . . . . . 583 Remote Access Device — Specific Exploits . . . . . . . . . . . . 583 Weak User Authentication . . . . . . . . . . . . . . . . . . . . . . . 583 Same Account and Login Multiple Devices . . . . . . . . . 584 Shared Login Credentials . . . . . . . . . . . . . . . . . . . . . . . . 584 Home User System Exploitation. . . . . . . . . . . . . . . . . . . . . . 584 Wireless Technology — Specific Exploits . . . . . . . . . . . . . . 585 Interception and Monitoring . . . . . . . . . . . . . . . . . . . . . 585 Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586 Rogue Access Points . . . . . . . . . . . . . . . . . . . . . . . . 586 Unauthorized Clients . . . . . . . . . . . . . . . . . . . . . . . . 586 Client-to-Client Attacks. . . . . . . . . . . . . . . . . . . . . . . . . . 587 Media Access (MAC) Address . . . . . . . . . . . . . . . . 587 Duplicate IP Address . . . . . . . . . . . . . . . . . . . . . . . . 587 Improper Access Point Configuration . . . . . . . . . . . . . 588 Service Set Identifier (SSID) . . . . . . . . . . . . . . . . . . 588 Default SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588 xxix

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS SSID Broadcasting. . . . . . . . . . . . . . . . . . . . . . . . . . . 588 Limit or Disable In-Band Access (via Telnet, Use Access Lists to Protect Terminal, SNMP, Limit Use of Internal Web Servers Used Disable Cisco Discovery Protocol (CDP) Keep Up-to-Date on Security Fixes for Watch for Traffic Where the Source Enforce Minimum Fragment Size to Protect against Tiny Fragment Attack, Overlapping Disable Small Services (No Service Small-Servers Use Traffic Shaping (Committed Access Rate) Wired Equivalent Privacy (WEP) Exploits . . . . . . . 588 Network Infrastructure Security and Controls . . . . . . . . . . . . . 589 Defensive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 Routing Protocol Security Options . . . . . . . . . . . . . . . . . . . 589 Management Security Options . . . . . . . . . . . . . . . . . . . . . . . 590 Operating System Hardening Options . . . . . . . . . . . . . . . . . 590 Protecting Running Services . . . . . . . . . . . . . . . . . . . . . 590 Hardening of the Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . 592 Explicitly Shut Down All Unused Interfaces . . . . . 592 SSH, SNMP, Etc.). . . . . . . . . . . . . . . . . . . . . . . . . 592 Reset All Default Passwords . . . . . . . . . . . . . . . . . . 593 Use Encrypted Passwords. . . . . . . . . . . . . . . . . . . . 594 Use Remote AAA Authentication . . . . . . . . . . . . . . 594 TFTP Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 Remote Login (Telnet) Service . . . . . . . . . . . . . . . . . . . 595 SNMP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 Routing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 Limit Use of SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 596 for Configuration . . . . . . . . . . . . . . . . . . . . . . . . 596 on Cisco Gear Outside of the Firewall. . . . . . . 596 Do Not Leak Info in Banners . . . . . . . . . . . . . . . . . . 596 Your Network Infrastructure Devices . . . . . . . 597 DoS and Packet Flooding Controls . . . . . . . . . . . . . . . . 597 Use IP Address Spoofing Controls . . . . . . . . . . . . . 597 and Destination Addresses Are the Same. . . . 597 Fragment Attack, and Teardrop Attack. . . . . . 598 Disable IP Unreachables on External Interfaces . . 598 Disable ICMP Redirects on External Interfaces . . 598 Disable Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . . . 598 Disable IP Directed Broadcasts (SMURF Attacks). . 598 UDP and No Service Small-Servers TCP) . . . . 598 Disable IP Source Routing (No IP Source-Route) . . 598 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 xxx

Contents Configuration Audit and Verification Tools. . . . . . . . . . . . . 599 Wireless Network Controls . . . . . . . . . . . . . . . . . . . . . . . . . . 599 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 Request for Comments (RFCs) . . . . . . . . . . . . . . . . . . . . . . . 602 White Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 Web References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 PART III CONSOLIDATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 16 Consolidating Gains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 Active Directory Privilege Reconnaissance Built-In/Default Accounts, Groups, File System Exploitation through Extended File System Functionality Starting/Stopping Services and Executing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 Consolidation (OS and Network Facilities) . . . . . . . . . . . . . . . . 607 Account and Privilege Management Facilities . . . . . . . . . . 608 Account Cracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608 SMBCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 and Hacking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612 and Associated Privileges . . . . . . . . . . . . . . . . . . . . 612 Finger Service Reconnaissance . . . . . . . . . . . . . . . . . . . 613 Kerberos Hacking and Account Appropriation . . . . . . 613 Keystroke Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613 LDAP Hacking and LDAP Reconnaissance . . . . . . . . . . 615 Polling the Account Database . . . . . . . . . . . . . . . . . . . . 615 Social Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617 Trojanized Login Programs . . . . . . . . . . . . . . . . . . . . . . 617 File System and I/O Resources . . . . . . . . . . . . . . . . . . . . . . . 617 File System and Object Privilege Identification. . . . . . 618 File System (Operating System) Hacking . . . . . . . . . . . . . . 624 File Sharing Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 NFS (IP) Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 SMBRelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634 File Handle/File Descriptor Hacking . . . . . . . . . . . . . . . 635 File System Device and I/O Hacking . . . . . . . . . . . . . . . 637 Application Vulnerabilities . . . . . . . . . . . . . . . . . . . 637 Application-Based File System Hacking . . . . . . . . . . . . . . . 639 and File System Hacking . . . . . . . . . . . . . . . . . . . . . 639 Service and Process Management Facilities. . . . . . . . . . . . 640 Processes, Services, and Privilege Identification. . . . . . . . 641 with Specific Privileges . . . . . . . . . . . . . . . . . . . . . . 650 xxxi

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS API, Operating System, and Application Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652 Buffer Overflows, Format String, Inter-Process Communication (IPC), Named Pipe, Account/Privilege Appropriation via and Other Application Attacks . . . . . . . . . . . . . . . . . . . 654 Debugging Processes and Memory Manipulation . . . . . . . 655 and Named Socket Hacking . . . . . . . . . . . . . . . . . . . 657 Devices and Device Management Facilities . . . . . . . . . . . . 661 Devices and Device Management Hacking . . . . . . . . . . 662 Keystroke Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 Packet Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 Libraries and Shared Libraries . . . . . . . . . . . . . . . . . . . . . . . 662 Library (and Shared Library) Hacking . . . . . . . . . . . . . 664 Shell Access and Command Line Facilities . . . . . . . . . . . . . 669 Shell Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670 Registry Facilities (NT/2000). . . . . . . . . . . . . . . . . . . . . . . . . 672 Registry Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672 Client Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674 Client Software Appropriation . . . . . . . . . . . . . . . . . . . . 674 Listeners and Network Services . . . . . . . . . . . . . . . . . . . . . . 677 a Vulnerable Network Service. . . . . . . . . . . . . . . . . 677 NetBIOS/SMB Reconnaissance. . . . . . . . . . . . . . . . . . . . 677 Network Information Service (NIS) Reconnaissance . . . . . 682 NIS Hacking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685 SNMP Reconnaissance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688 Network Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . 690 Account Cracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692 Token Capture and Impersonation . . . . . . . . . . . . . . . . 692 Application/Executable Environment . . . . . . . . . . . . . . . . . 693 Consolidation (Foreign Code) . . . . . . . . . . . . . . . . . . . . . . . . . . . 693 Trojans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694 Backdoors (and Trojan Backdoors) . . . . . . . . . . . . . . . . . . . 698 Backdoor Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Backdoor Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702 Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707 Kernel-Level Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714 Mapping Exploits to Defenses . . . . . . . . . . . . . . . . . . . . . . . . . . . 715 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 References and System Hardening References. . . . . . . . . . 725 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 Web References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 xxxii

Contents System Hardening References . . . . . . . . . . . . . . . . . . . . . . . 725 Windows NT/2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726 17 After the Fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727 Logging, Auditing, and IDS Evasion . . . . . . . . . . . . . . . . . . . . . . 729 Logging and Auditing Evasion . . . . . . . . . . . . . . . . . . . . . . . 729 Windows NT/2000 Logging/Auditing Evasion . . . . . . . 731 IP Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738 Account Masquerading . . . . . . . . . . . . . . . . . . . . . . 738 Deletion/Modification of Log File Entries . . . . . . . 739 Deletion of Log Files. . . . . . . . . . . . . . . . . . . . . . . . . 743 Disabling Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 743 Controlling What Is Logged. . . . . . . . . . . . . . . . . . . 743 Manipulation of Audit Options . . . . . . . . . . . . . . . . 743 Deletion or Update of Audit Files . . . . . . . . . . . . . . 744 UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744 UNIX Logging/Auditing Evasion. . . . . . . . . . . . . . . . . . . 750 IP Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750 Account Masquerading . . . . . . . . . . . . . . . . . . . . . . 750 Deletion/Modification of Log File Entries . . . . . . . 751 Deletion of Log Files. . . . . . . . . . . . . . . . . . . . . . . . . 751 Disabling Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . 752 Controlling What Is Logged. . . . . . . . . . . . . . . . . . . 752 Manipulation of Audit and Accounting Options. . 752 Deletion or Update of Audit Files . . . . . . . . . . . . . . 753 Routers (Cisco) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753 AAA Protocols (RADIUS, TACACS) . . . . . . . . . . . . . . . . 756 Centralized Logging Solutions (Syslog) . . . . . . . . . . . . 757 IP Spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758 Account Masquerading . . . . . . . . . . . . . . . . . . . . . . 758 Deletion/Modification of Log File Entries . . . . . . . 759 Deletion of Log Files. . . . . . . . . . . . . . . . . . . . . . . . . 759 Disabling Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Controlling What Is Logged. . . . . . . . . . . . . . . . . . . 759 IDS Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759 Forensics Evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760 Environment Sanitization . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 Sanitizing History Files . . . . . . . . . . . . . . . . . . . . . . . . . . 763 Sanitizing Cache Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 763 File Hiding and File System Manipulation . . . . . . . . . . . . . . 764 Operating System File Hiding Techniques . . . . . . . . . . 765 Alternate Data Streams (NT/2000/XP) . . . . . . . . . . . . . 774 Steganography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775 Cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777 xxxiii

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Covert Network Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 Establishment of Appropriate Access Controls Implementation of Tools for Remote Monitoring Strict Management of Audit and Covert TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779 “Normalizing” Traffic (Covert Shells) . . . . . . . . . . . . . . 781 ICMP Covert Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 783 Investigative, Forensics, and Security Controls . . . . . . . . . . . . 785 Mapping Exploits to Defenses. . . . . . . . . . . . . . . . . . . . . . . . 785 Centralized Logging and Archival of Log File Data . . . 785 Centralized Reporting and Data Correlation . . . . . . . . 787 Encryption of Local Log File Data . . . . . . . . . . . . . . . . . 787 for Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787 of Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788 Patches and Software Updates . . . . . . . . . . . . . . . . . . . 788 Process Monitoring for Logging Services. . . . . . . . . . . 789 Regular File System Audits. . . . . . . . . . . . . . . . . . . . . . . 789 Accounting-Related Privileges . . . . . . . . . . . . . . . . 789 Traffic Encryption for Syslog Packet Data . . . . . . . . . . 789 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Web References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792 18 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793 Conclusion: Case Study in Subversion . . . . . . . . . . . . . . . . . . . . 795 Dalmedica’s Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 Bastion Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Reconnaissance Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Target Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 Conclusion (Final Thoughts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 Areas of Focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 General Hacking and Security Resources . . . . . . . . . . . . . . 823 Authentication Technologies . . . . . . . . . . . . . . . . . . . . . . . . 823 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 DNS and Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . 824 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Route/Switch Infrastructures . . . . . . . . . . . . . . . . . . . . . . . . 824 Storage Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Voice over IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Wireless Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 xxxiv

Chapter 1 Introduction: The Chess Game When you see a good move, look for a better one. — Emanuel Lasker Chess, like any creative activity, can exist only through the combined efforts of those who have creative talent and those who have the ability to organize their creative work. — Mikhail Botvinnik Good offense and good defense both begin with good development. — Bruce A. Moon Botvinnik tried to take the mystery out of chess, always relating it to sit uations in ordinary life. He used to call chess a typical inexact problem similar to those which people are always having to solve in everyday life. — Garry Kasparov A chess game is a dialogue, a conversation between a player and his opponent. Each move by the opponent may contain threats or be a blunder, but a player cannot defend against threats or take advantage of blunders if he does not first ask himself: What is my opponent plan ning after each move? — Bruce A. Moon 0-8493-0888-7/04/$0.00+$1.50 © 2004 by CRC Press LLC 1

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS In many ways, this is almost the hardest chapter to pen in this book; in writ ing this, I am forced to relive the many occasions on which I have stood in a bookstore leafing through a technical book, trying to determine its value to the technical “excursion” I am currently embarked on. I generally start with the preface … (sigh). For this particular book, putting together an accurate, representative preface is a daunting task; The Hacker’s Handbook was deliberately constructed as a multifaceted text. Let me try — this book is about hacking, yes, but it is also weighted towards the security community. At the time when the authors started framing the book (May 2001), a significant number of books on the subject of digital hacking and security had already been published. In an effort to make some “space” for this book, we reviewed many of them and came to the conclusion that there was room for a book that adopted an analytical perspective on hacking and security and attempted to inform readers about the technical aspects of hacking that are, perhaps, least understood by system, network, and security administrators. To this end, we compiled a list of objectives that truly informed the way in which this book was constructed: • Chapters should maintain a dichotomy between hacking and security, intended to inform the reader’s understanding of both. Most chapters are deliberately broken into (1) technical (background), (2) hacking, and (3) security sections; the intent of this approach is to inform the way in which administrators defend systems and networks by exploring hacking exploits and defenses in the same technical context. • Chapters should be organized around specific technical and adminis trative components (e.g., specific services such as SMTP, HTTP, DNS, directory services and specific administrative tasks, system harden ing, forensics investigation, etc.), to facilitate using the book as a technical security reference. If you are a DNS administrator, for example, you should be able to quickly locate material relevant to DNS hacking and DNS security. • There should be an emphasis on providing a sound technical and conceptual framework that readers can apply throughout the book. Key foundation chapters address the following: – Attack anatomy (Chapter 4) – Security technologies (Chapter 5) – Programming (Chapter 6) – Transmission Control Protocol/Internet Protocol (TCP/IP) attacks (Chapters 7 and 8) – Postattack consolidation (Chapters 17 and 18) • The book should maintain a dual perspective on theory and tools, intended to provide a rounded approach to the subject matter. Each 2

Introduction: The Chess Game chapter is organized to provide an appropriate theoretical founda tion for the chapter material as a frame of reference for the reader. Tools, exploit code, and hacking “techniques” are analyzed in this context but with sufficient latitude to reinforce the fact that hacking is still a “creative” activity. • Chapters should provide detailed reference material to provide a “path” for readers to continue to augment their knowledge of the field and act as a guide to consolidating the sheer volume of hacking and security information available through the Internet and other resources. Providing this information is also intended to ensure that the technical material presented in this book is enduring. As indicated, the book is oriented toward systems, network, and security administrators with some degree of security experience who are looking to expand their knowledge of hacking techniques and exploits as a means of informing their approach to systems and network security. This orienta tion makes for a fairly broad audience and is reflected in the breadth of the material presented. To ensure that the book delivers on this objective, each chapter contains a table mechanism and chapter section that delib erately “maps” hacking exploits to prospective defenses, and each chapter ends with a treatment of prospective security defenses. The only practical limitation to the book material is that the authors chose to focus on the Microsoft Windows NT/2000 and UNIX platforms; the volume and depth of technical material presented in the book necessi tated setting some scope constraints. The authors felt that there might be value in limiting the range of platforms represented in the text to add more technical depth to the application hacking material. Rather than under- representing platforms such as Novell or Mainframe/Midrange, the deci sion was made to exclude them altogether. To reinforce the positioning of hacking and security material in the book, a “chess game” analogy has been played throughout the material (none of the authors, by the way, are particularly good chess players). The dynamics and strategy of chess were thought by the authors to have several parallels with the subject matter presented in this book: • As with many other strategic games, the success of either party in the chess game depends upon that party’s ability to enhance his or her skills relative to his or her opponent’s. • Chess players engage, to varying extents, in an attempt to predict the moves of their opponents so that they can prevail and checkmate their opponents. • Chess is essentially a game of move and countermove; hacking and security tactics can be conceived of in the same manner. • Defensive strategies exist in hacking and security, but an aggressive and creative attacker can overcome them. 3

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS • Offensive strategies also exist, but intelligent and vigilant defenders can counter them. • Poorly executed plans or rigid adherence to a plan is less effective than learning and adjusting as the chess game progresses. • The whole hacking vs. security “chess match” can turn upon a single move. Use of this analogy is also intended to credit the general hacking com munity for its resourcefulness in pursuing new types of vulnerabilities and exploit code. It is not a perfect analogy (defenders generally do not attack their attackers, for example), but it is pretty close. The chess game theme has been reinforced in this book through the incorporation of a series of illustrations (by Trevor Young) that lend some art (and humor) to the subject matter. Susan Young March 2003 Book Structure The Hacker’s Handbook has been organized into several sections to aid the reader’s understanding of the material being presented (see Exhibit 1). The first part of the book (Part I. Foundation Material) introduces pro gramming, protocol, and attack concepts that are applied throughout the book. The second part of the book (Part II. System and Network Penetration) addresses specific subject areas (protocols, services, technologies, hack ing facilities, hostile code) that relate to system and network penetration. The final part of the book (Part III. Consolidation) details the types of con solidation activities conducted by hackers once a system or network has been successfully penetrated to establish and expand a “presence.” The following information provides a detailed breakdown on the con tent of each chapter. Chapter 2. Case Study in Subversion The concept behind this chapter is to present a case study that demon strates what a complex network attack looks like from an administrator’s perspective. The conclusion (Chapter 18) to the book revisits the initial case study material from an attacker’s perspective, leveraging the techni cal material presented throughout the book. The case study adopts a couple of fictional characters (a hacker and net work administrator) and charts their moves as the attack unwinds using system and device log files, screens, etc., and a fairly complex network based around a reasonable security architecture. 4

Introduction: The Chess Game Exhibit 1. Layout of The Hacker’s Handbook Chapter Title Ch. 1 Introduction: The Chess Game Part I Foundation Material Ch. 2 Case Study in Subversion Ch. 3 Know Your Opponent Ch. 4 Anatomy of an Attack Ch. 5 Your Defensive Arsenal Ch. 6 Programming Ch. 7 IP and Layer 2 Protocols Ch. 8 The Protocols Part II System and Network Penetration Ch. 9 Domain Name System (DNS) Ch. 10 Directory Services Ch. 11 Simple Mail Transfer Protocol (SMTP) Ch. 12 Hypertext Transfer Protocol (HTTP) Ch. 13 Database Hacking Ch. 14 Malware and Viruses Ch. 15 Network Hardware Part III Consolidation Ch. 16 Consolidating Gains Ch. 17 After the Fall Ch. 18 Conclusion Chapter 3. Know Your Opponent Chapter 3 presents a history of hacking and the different elements who constitute the hacking community, providing a potential “profile” of a hacker — script kiddie, hacker, cracker, competitor, political activist, cyber terrorist, Gray Hat, Black Hat, etc. This chapter is intended to provide some insight into hacking psychology and hacking motivation. Chapter 4. Anatomy of an Attack Chapter 4 presents an “anatomy” of various types of attacks and a taxonomy of the tools appropriated in the process. Five elements of attack strategy are presented in a model that opens the chapter: • Reconnaissance • Mapping targets • System or network penetration • Denial-of-service • Consolidation (consolidation tactics are discussed in detail in Chapter 16) 5

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS “Generic” types of attack are briefly overviewed in this chapter as con text for the technical chapters that follow, including account attacks, buffer overflows, denial-of-service, session hijacking, spoofing, etc. Each chapter segment concludes with a “Tools” section that provides a table of references to applicable tools and pointers to source code and Web references. Chapter 5. Your Defensive Arsenal This chapter dissects the tools employed by administrators to defend a networked environment and examines the vulnerabilities and types of exploits each are prone to. The following framework is used to organize the security technologies presented in the chapter: • Access control • Authentication • Auditing and logging • Resource controls • Nonrepudiation • Privacy • Intrusion detection • Data integrity • Platform integrity Chapter 6. Programming Chapter 6 is a technical “foundation” chapter and could be considered the technical complement of the “Protocols” chapters that follow. The chapter addresses the programming flaws exploited by attackers in constructing exploit code and the methodology and programming facilities they draw upon in building a hacking exploit. Written for the nonprogrammer, the chapter details various types of compiled and interpreted languages and investigates the following types of programming deficiencies and hacking facilities: • Language-specific flaws • Buffer overflows and memory allocation errors • Format string bugs • Interpreter bugs • Canonicalization attacks • Logic errors • Platform-specific security issues • Web application issues • Remote procedure call (RPC) vulnerabilities 6

Introduction: The Chess Game The chapter ends by examining different programming mindsets, what “pits” programmer against programmer, and tools available to software programmers for validating the security of the software they develop. Chapter 7. IP and Layer 2 Protocols Chapter 8. The Protocols The Protocols chapters focus on the TCP/IP protocols and examine some of the “generic” TCP/IP exploits and denial-of-service attacks and defenses against them. Specific protocol material, in some instances, is deferred to later chapters. The chapters focus on the fundamental vulnerabilities in TCP/IP that are exploited by hackers and some of the ongoing IP security initiatives intended to address these. Each protocol is examined using the OSI reference model as context: • Layer 2 protocols: Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) • Layer 3 protocols: Internet Protocol (IP), Internet Control Messaging Protocol (ICMP); routing protocols such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), and Border Gateway Protocol (BGP) are overviewed in the chapter “Network Hardware” (Ch. 15); IP Security Protocol (IPSec) is detailed in “Your Defensive Arsenal” (Ch. 5) • Layer 4 protocols: Transmission Control Protocol (TCP), User Data gram Protocol (UDP) • Layer 5 protocols: Secure Sockets Layer (SSL) addressed in “Your Defensive Arsenal” (Ch. 5) • Layer 7 protocols: Each addressed in its respective chapter (DNS, HTTP, Lightweight Directory Access Protocol [LDAP], Open Database Connectivity [ODBC], Remote Procedure Call [RPC], SMTP, Simple Network Management Protocol [SNMP], Structure Query Language [SQL], etc.) A great deal of material is dedicated to the IP protocol, which has some fundamental security flaws that allow it to be used as a transport for net work attacks. Chapter 9. Domain Name System (DNS) The focus of this chapter is the Domain Name System, which is treated as a critical Internet “directory” service and a fragile link in Internet secu rity. This chapter explores the significance of DNS as a target for hacking activity and denial-of-service and its appropriation in the construction of reconnaissance and application attacks. The following types of exploits are examined in the chapter: 7

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS • Reconnaissance attacks • Cache poisoning • Application attacks • Denial-of-service • Dynamic name registration hacking • Client/server spoofing • Name server hijacking The final section of this chapter provides a set of tools for securing, sub stantiating, and monitoring a name service infrastructure and includes information on split-level DNS implementations, name server redundancy, dynamic client security, and the use of digital signatures to secure name server content. Chapter 10. Directory Services This chapter provides information on the various types of directory services in common use on networks and the types of hacking and reconnaissance exploits to which each is prone. The following directory services and direc tory service protocols are discussed in some detail: • Microsoft Active Directory • LDAP • X.500 directory services As with prior chapters, this chapter explores some of the generic types of hacking exploits leveraged against directory services and the specifics of vulnerabilities in particular implementations. The chapter also overviews directory security and examines directory security in the context of specific applications of directory services (such as public key infrastructure). Chapter 11. Simple Mail Transfer Protocol (SMTP) Chapter 11 analyzes the Simple Mail Transfer Protocol (SMTP) as a core Internet and private network service and a significant “vector” for the propa gation of malicious code and the construction of denial-of-service attacks. Key vulnerabilities in the SMTP protocol are detailed as context for the hacking material, and mail hacking is explored through the dissection of a variety of attacks, exploit code, and packet data, including: • Mail eavesdropping and reconnaissance • ESMTP hacking • Denial-of-service • Mail spamming and relaying • Mail spoofing • MIME hacking 8

Introduction: The Chess Game The conclusion to the chapter addresses the facilities available to administrators for hardening SMTP servers and some of the SMTP security initiatives intended to address specific vulnerabilities in the protocol (such as Secure/Multipurpose Internet Mail Extensions [S/MIME]). Chapter 12. Hypertext Transfer Protocol (HTTP) The HTTP chapter addresses the significance of HTTP as a hacking target in light of the advent of Internet commerce and the transport of a variety of sensitive personal and commercial data via HTTP. HTTP servers are fre quently used to provide an accessible Web front-end to complex, back-end database and custom applications, affording hackers a “conduit” through which to mount application and data reconnaissance attacks. HTTP hacking is explored through dissection of the following types of attacks: • Eavesdropping and reconnaissance • Account cracking and authentication credential capture • HTTP method exploits (POST, PUT, etc.) • HTTP cache exploits • Denial-of-service • Directory traversal attacks • Session ID hacking • Man-in-the-middle attacks The chapter concludes by examining HTTP security mechanisms such as SSL, caching controls, digital certificate or signature security, and session ID security options. Chapter 13. Database Hacking Database hacking and database security represent an enormous body of material. This chapter focuses on vulnerabilities in specific types of data base technologies (SQL Server, Oracle, MySQL) to illustrate some basic points about database hacking and data security. General themes include: • SQL injection • Overflows • Exploitation of default accounts Representative database applications and examples are drawn upon to add “depth” to the material and to document the process of identifying and exploiting a vulnerable database application. Chapter 14. Malware and Viruses This chapter addresses various forms of hostile code that can be used to achieve denial-of-service, data destruction, information capture, or intrusion. Definitions are provided for each type of malware for context. These include: 9

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS • Viruses • Worms • Hoaxes • Backdoors • Logic bombs • Spyware • Adware The chapter also details some of the programming and scripting lan guages and application facilities that are used to produce hostile code. Chapter 15. Network Hardware Chapter 15 addresses vulnerabilities in network hardware and associated firmware, operating systems, and software. The chapter opens with a broad discussion of the growing significance of network hardware (routers, switches, etc.) as a target for hacking activity and by providing a broad overview of the types of hacking exploits to which each hardware compo nent (hardware, firmware, software) is susceptible: • Attacks against routing or switching infrastructures • Routing protocol attacks (RIP, OSPF, etc.) • Management attacks (SNMP, HTTP, etc.) • Operating system/Internet operating system (OS/IOS) attacks • Denial-of-service • Wireless hacking • Packet switching attacks • Remote access attacks • Attacks against redundant network components The final chapter section addresses the security options in network hardware, protocol, management, and operating system (OS) facilities that can be leveraged to harden a network device or network, including packet flooding controls, wireless network security, OS/IOS hardening, routing protocol access control lists, and authentication controls. Chapter 16. Consolidating Gains Chapter 16 is the first of two chapters to address the tactics and tools employed by attackers to consolidate their position on a system or net work — essentially, the tasks that are undertaken by attackers to ensure consistent, covert access to a system or network resource or to extend their privileges as they relate to that resource. It demonstrates the effec tiveness of the hacking community’s knowledge of common system administration practices, standard system builds, and default application configurations; the intent of this chapter is to attempt to inform the way in which system and network administrators approach the management of these facilities from a “counter-tactics” perspective. 10

Introduction: The Chess Game Consolidating Gains explores the use of standard operating systems and network facilities for consolidation activities, in addition to the application of “foreign” exploit code: • Standard OS and network facilities – Account and privilege management facilities – File system and input/output (I/O) resources – Service management facilities – Process management facilities – Devices and device management facilities – Libraries and shared libraries – Shell access and command line interfaces – Registry facilities (NT/2000) – Client software – Listeners and network services – Network trust relationships – Application environment • Foreign code – Trojan horses – Backdoors (including Trojan backdoors) – Rootkits – Kernel-level rootkits The closing section of the chapter presents a collection of procedures and tools that can be used to stem consolidation activities; the focus of this material is cross-platform system hardening strategy. Chapter 17. After the Fall After the Fall addresses forensics evasion and forensics investigation. From a hacking perspective, this includes the techniques and tools hack ers employ to evade audit or logging controls and intrusion detection mechanisms, as well as covert techniques used to frustrate investigative actions and avoid detection. For the system or network administrator, a considerable amount of material on the preparations that should occur prior to a security incident is presented, along with measures for protect ing audit trails and evidence. The following types of hacking exploits are addressed: • Logging and auditing evasion (by platform): NT/2000; UNIX; router; authentication, authorization, and accounting (AAA) protocols, etc. • Intrusion detection system (IDS) evasion (linked to material in Chapter 5, “Your Defensive Arsenal”) • Forensics evasion – Environment sanitization – File hiding (including steganography, cryptography) and file system manipulation – Covert network activities (including IP tunneling, traffic normali zation) 11

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS The chapter closes with an examination of the types of tools and tactics security administrators can leverage to improve capabilities to detect and investigate security incidents, including protections for log files and audit trails, IDS, data correlation solutions, forensics technologies, and incident handling capabilities. Chapter 18. Conclusion The final chapter of The Hacker’s Handbook reviews the case study material presented in Chapter 2 in the context of the technical material presented throughout the book. The case study is examined from the attacker’s per spective and from the perspective of a network administrator investigating the incident. The chapter concludes with a set of references that supplement the references provided at the end of each chapter: • Security sites • “Underground” sites • Technical standards • Ongoing technical “themes” in hacking and security 12

Part I Foundation Material

Chapter 2 Case Study in Subversion This case study — really the “chess game” at work — is unique among the chapters presented in this book. The case study examines the actions of a fictitious administrator, hacker, and investigator in the context of a series of security events that beset a fictional company (Dalmedica). These events are depicted from a “defensive” standpoint — from the standpoint of the administrator and investigator trying to make sense of them — using a “real” network. The network, systems, and application environment cho sen for the case study is dynamic, transitions over the course of the study timeline, and is representative of a reasonably sound security design. The events that occur are illustrations of hacking exploits and attacks presented in the remainder of the book but are represented from a “symptomatic” per spective; later chapters illuminate and explain the types of attacks alluded to in the case study. This chapter is paired with the Conclusion (Chapter 18) of the book, which revisits the case study material from the attacker’s perspective. Dalmedica Dalmedica is a (fictitious) six-year-old public corporation that develops software for the medical industry. Its most recent software development venture — due for release at some point over the next three months — involves a product called Medicabase that assists medical researchers in analyzing, correlating, and securing patient data as part of clinical trial management. Dalmedica has been aggressively marketing some of the concepts behind Medicabase for some time, and the software has become somewhat controversial because of the “hooks” it potentially provides third parties into patient clinical data. Competitors have shown interest in the product from a competitive standpoint because of its technological advances and have been scouting for ways to further some of the “political” controversy surrounding the product in the hopes that this will negatively impact sales and market share once it goes to market. Dalmedica operates a medium-sized network of some 650 nodes (see Exhibit 1). The company went through a significant network efficiency 0-8493-0888-7/04/$0.00+$1.50 © 2004 by CRC Press LLC 15

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Exhibit 1. Network Diagram IDS Stateful Packet Filtering Firewall VPN Server SMTP Gateway (Anti-Virus and Content Filtering) Web Farm Web Content Filtering Gateway Private LAN (172.30.0.0/16) INTERNET ISP-Managed Router Internet DMZ Load Balancing Device IDS Dial-up Server Extranet DMZ Partner Extranet Application Proxy Firewall (Primary (Public) DNS Server) 204.70.10.240/29 (Publicly Addressed IP Network) 204.70.10.208/28 (Publicly Addressed IP Network) 204.70.10.224/28 (Publicly Addressed IP Network) 204.70.10.192/28 (Publicly Addressed IP Network) Partner Network Connection Partner Net (Router ACLs) Server Network (Fully Switched) DNS Server(s) (Primary and Secondary) Active Directory/ Domain Controller (and Backup Domain Controllers) Corporate Mail Server IDS Database Servers Corporate LAN (Switched to the Desktop) Clients, Printers, etc. (500 nodes) QA/Development LAN (Fully Switched) Clients Development Servers (UNIX/NT) Syslog Server .246 .241 .245 .228, .229, .230.208 .224 .193 .221 .194, .195 .209 .210 .211 172.30.0.1 assessment and reorganization two years ago, and the internal network is (for the most part) fully switched and organized into virtual local area net- works (VLANs) that correspond with operational domains (development, quality assurance [QA], finance, etc.). The security architecture consists of 16

Case Study in Subversion a two-tier firewall environment (stateful perimeter firewall, application- level local area network [LAN] firewall), with network-based intrusion detection systems (IDSs) in place at the Internet connection, on the Web demilitarized zone (DMZ), and on the private LAN. Dalmedica uses a split- level (public vs. private) Domain Name System (DNS) configuration1 and has implemented a mail gateway and content scanning gateway that scan all mail and Web content exiting or entering the main corporate LAN. Log ging is centralized via a syslog server (although local logging is still per formed on a number of systems) and a Microsoft Active Directory/Domain architecture has been established to authenticate users to specific resources on the network. From an administrative perspective, network, systems, and application administration is divided among several technical groups that fall under the corporate information technology (IT) function. Security management is performed by a parallel organization that consists of policy and technology branches and interfaces with respective groups within IT. IT and security operations are primarily integrated via the corporate incident handling team, which meets on a regular basis to inspect and respond to vulnerability reports and security threats. Web and operations application development is considered a development function and is managed within the develop ment organization, subject to the same development and QA process as product software development. Dalmedica leverages consultants for specific project tasks and contracts an outside security consulting firm to perform a periodic annual security risk assessment and to conduct external and extranet penetration test ing, as deemed appropriate. Dalmedica security management also has the ability to call in specialists, such as forensic specialists or criminal investi gators, where necessary, although the company has never had cause to do this. The Dilemma Scott Matthews was confused by what was happening. Within the last ten minutes, two critical problems had emerged on the network: no network clients could get out to the Internet, and Internet users were having prob lems accessing Dalmedica’s Web servers. His first instinct was that it was a connectivity problem, and so he telnet-ed to Dalmedica’s Internet router, ran a series of ICMP connectivity tests to the next hop router and arbitrary Internet sites, and placed a call to EnterISP, Dalmedica’s Internet service provider. “Hi, this is Scott Matthews, network operations manager for Dalmedica. We’re seeing some Internet connectivity problems that I was wondering if you could help me investigate?” The technician worked with Scott in inspecting packet response times to and from Dalmedica’s Internet handoff 17

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS and identified that there was some latency and congestion not just on Dalmedica’s Internet link but also on associated areas of EnterISP’s network. Traceroutes to Dalmedica’s Internet router revealed the following: $ traceroute gw.dalmedica.com tracing route to gw.dalmedica.com (204.70.10.246), 30 hops max 1 gw1.enterisp.net (211.198.12.30) 5.412ms 5.112ms 5.613ms 2 core1.enterisp.net (211.197.22.15) 30.160ms 34.576ms 34.180ms 3 core2.enterisp.net (210.105.60.17) 770.433ms 890.899ms 920.891ms 4 gw.Dalmedica.com (204.70.10.246) * * * Request timed out. “Scott, let me examine this a little further, and I’ll get back to you,” the technician responded. Scott and the technician exchanged contact informa tion and hung up. Scott sat back in his chair, paged through the messages on his pager and thought for a second. Returning access to the corporate Web servers was probably the highest priority — perhaps it was worthwhile taking a couple of seconds to examine the firewall log files. He started a session to the corporate application proxy firewall using a firewall manage ment client and inspected the current log file. What he saw startled him — hundreds of DNS connection requests for domains for which the firewall (Dalmedica’s primary/public DNS server) was not authoritative. “**?%~!,” he exclaimed, “a denial-of-service attack?”2 A bevy of source addresses was associated with the recursive DNS requests; Scott performed a couple of DNS IP-to-hostname lookups using nslookup to try to identify some of them. A portion returned hostnames:3 nslookup Default server: ns1.enterisp.net Address: 210.10.10.249 > set q = ptr > 8.60.122.199.in-addr.arpa 8.60.233.199.in-addr.arpa Name = bandit.mischevious.com > 9.150.17.66.in-addr.arpa 9.150.17.66.in-addr.arpa Name = rogue.outasitecollege.edu “Oh, this looks worse and worse.” He was just considering his next move (and expletive) when his manager popped his head around the door. “Scott, what’s going on?” questioned Bob. Scott responded with “Someone is mounting what appears to be a denial-of-service against us, but I think I can stem it by turning off support for Internet recursion at the firewall.3 I’ll still need to contact EnterISP to 18

Case Study in Subversion see if they can help me stem any associated packet flooding. Also, our desk tops don’t seem to be able to get out to the Internet; this may be a related problem due to the link congestion.” “Well, whatever it is, we need to get to the bottom of it quickly,” stated Bob, “Tom Byrd just informed me that marketing is getting ready to put out a preliminary press release on Medicabase this morning, and they’ll be posting a link to additional information on our Web site. Let me know if you get stalled with this…” Scott visibly sank in his chair — it was days like this when he wished he had abandoned a technical career and taken up something “safe” such as vertical freefall skydiving. He focused, turned back to the firewall, and disabled support for Internet recursion — this would have no impact on Dalmedica Web site access but would prevent the attacker from being able to force the firewall/name server to perform exhaustive Internet lookups on behalf of anonymous hosts. Performance at the firewall seemed to leap as the change was successfully written out. Scott turned to his phone and called the head of the security incident handling team — Mike Turner — and informed him that he thought he had a security incident on his hands. “OK, keep calm,” stated Mike (in a panicked voice), “I’ll contact a couple of people and we’ll start an investigation to determine if this is a legitimate incident.” Dalmedica’s LAN clients were still experiencing problems accessing the Internet — Scott noted that there was an absence of the general HTTP “clutter” he was used to seeing in the firewall log files. He waited a minute, willing the screen to start popping client HTTP requests — nothing. “Ah, there’s one,” he exclaimed, as a lone entry populated the log file, “Hmmm… something’s not right here...” He swung around in his seat to a server sitting next to him, and started a browser session to an Internet Web site (see Exhibit 2). Scott was confounded. He went to the command prompt on the system, fired up nslookup and tried performing DNS lookups for some well-known Internet sites: C:\>nslookup DNS request timed out. timeout was 2 seconds. *** Can't find server name for address 210.10.10.249: Timed out *** Default servers are not available Default Server: UnKnown Address: 210.10.10.249 19

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Exhibit 2. Failed Attempt to Connect > set q = any > www.enterisp.net Server: UnKnown Address: 210.10.10.249 *** UnKnown can't find www.enterisp.net: No response from server > As each successive DNS request failed, he sagged. Scott swung back to the firewall, launched a command prompt, and used nslookup to perform some DNS lookups. Every DNS request he issued from the firewall received a successful response. Intrigued, Scott pondered the problem for a second. He checked the resolver configuration on the “test” client as a sanity check and concluded that it was possible that this was a separate problem from the DNS denial-of-service and that it was worth inspecting the configura tion and logs on the internal DNS server. The log on the internal DNS server revealed the following: a.root-servers.net. 198.41.0.4 Can’t contact root NS: a-root.servers.net b.root-servers.net. 128.9.0.107 Can’t contact root NS: b-root.servers.net c.root-servers.net. 192.33.4.12 Can’t contact root NS: c-root.servers.net 20

Case Study in Subversion Scott shook his head. What was this? Had anyone performed any recent updates to the DNS server? A cursory inspection of the log didn’t reveal anything. He placed a call to the group responsible for DNS and IP manage ment within IT/systems and requested some assistance in investigating the problem. “Check the root name server hints file, which is located at c:\winnt\system32\dns,” responded the administrator. “It should point to the corporate firewall because we’re proxying DNS connections to the firewall.” Scott reviewed the contents of the file. “It looks like a standard root name server hints file to me,” he stated. “It contains a list of all of the Internet Root name servers and their respec tive IP addresses.” The DNS administrator was perplexed. “Well, there’s your problem. I don’t know who would have reverted the configuration, but you need to stop the DNS server, rename that file, and replace it with a file that uses the firewall’s inside interface as a root NS — that should solve the problem.” Scott accomplished the necessary changes and saw the firewall log file “leap” with the familiar HTTP clutter. He breathed a sigh of relief and picked up the phone to call his manager and report a successful return to normal operations. At that moment, Mike Turner, the head of the security incident team, appeared behind him. “So Scott, how are we doing?” “Well, we’re back to normal,” stated Scott, “…but I’d be grateful if you’d work with our ISP to try to determine who was mounting the DNS denial-of service — I’m going to grab some coffee.” *** Later that day, as Scott was returning from a long lunch and passing the development lab, he spotted a number of engineers and the development lab administrator crouched around a single terminal. He swiped his badge at the lab card reader and swept into the lab. “Hi guys, what’s going on?” he asked cheerfully, to the pained expressions in front of him. “We’re not sure yet,” replied one of the engineers. “It looks like we’re having a problem with some library corruption in one of the libraries on the source code server.” “Can we recover?” asked Scott. “Well, we can…” the source code librarian, Neil Beck responded, “…but I’d like to figure out how it happened so that we can prevent it from recurring.” Scott nodded. He exited the server room and headed to a nearby confer ence room for a management meeting to discuss the morning’s events. The ISP had not been able to trace the absolute source of the denial-of-service attack that occurred that morning but had gathered sufficient information to indicate that the attack was well organized and executed, and that it 21

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Exhibit 3. Sequence of Events System Event Description Account Two benign-looking accounts (cvstree and cvsmanager) had been manipulation created on the UNIX development server housing the Source Code Control System (SCCS) An account that belonged to an engineer who had recently left Dalmedica had been used to log on to the system on several occasions over the past two weeks; certain files in that user’s home and development directories had been created or updated, including files that facilitated remote access to the server Process table Neil made regular passes at the process table on the system and irregularities noted that there were a couple of additional services (and network listeners) running on the system; although this was not unusual (several developers had administrative access to the server), it was felt that, cumulatively, this required additional investigation Library corruption Libraries on the SCCS had apparently been updated or created; as a corollary to this, the LD_Library Path on the system had been updated — something considered a highly unusual system event; this activity had resulted in the replacement of some .c and .o files in library directories and the resulting library corruption Log file gaps There appeared to be a 20-minute window in the local log file on the SCCS that corresponded with the timing of the DNS denial-of service attack specifically targeted Dalmedica. As the meeting’s members speculated about the perpetrator(s) of the attack, one of the engineers stuck his head around the door of the conference room. “Scott, can I borrow you for a second?” Things were starting to look kind of grim. “Well, we didn’t think anything of the library corruption until we started to uncover some evidence that other files in the file system had been manipulated,” the engineer said. “Specifically, portions of our CVS-managed source code have been checked out using an unauthorized account.” Scott stopped in his tracks. “Neil can better explain the problem,” the engineer speculated, scuttling down the hallway towards the engineering lab. Neil and Scott reviewed Neil’s notes and recapped the sequence of events on the Source Code Control System (SCCS) (see Exhibit 3). “I stumbled across most of this while grep’ing through log files to trouble shoot the library problem,” explained Neil. “If you’re in agreement, I think we should bring the security incident handling team in to investigate this and this morning’s denial-of-service.” Scott concurred, as he began to con template whether it had really been wise to take such a long lunch. 22

Case Study in Subversion Examination of some of the systems that had trust relationships with the SCCS revealed some alarming activity. Random scans of some of the sys tems associated with the SCCS indicated that a Windows system that was used by one of Dalmedica’s administrators to Secure Shell (SSH) to the SCCS and other servers had been compromised with a Trojan backdoor. In addition, the .rhosts files on several associated UNIX systems had been updated with specific host and user names: devsys.dalmedica.com root devsys.dalmedica.com bschien (an ex-developer) crimson.dalmedica.com cvs Examination of logs and alarms from a network-based IDS situated on the corporate LAN had picked up unusual activity at several LAN systems over the past several weeks; an IDS installed to the Internet DMZ had also triggered over the same time period on a common gateway interface (CGI) script error and attempted privilege elevation attack: [**] [1:1122:1] WEB-MISC [**] [Classification: Attempted Privilege Escalation] [Priority: 2] 11/05-23:01:09.761942 208.198.23.2:1438 -> 204.70.10.229:80 TCP TTL:128 TOS:0x0 ID:10349 IpLen:20 DgmLen:314 DF ***AP*** Seq: 0x2277A4B3 Ack: 0xED9E771D Win: 0x4470 TcpLen: 20 As this information came to light and the prospective magnitude of the incident expanded, the incident handling team made a critical decision to augment the investigation by bringing in an outside computer forensics investigation team. It was the lead investigator on this team — Bill Freidman — whom Scott sat down with the following day to review the initial findings. The Investigation Bill scratched his head and grimaced, “So the DMZ IDS was recently installed? Have there been any other recent changes to your network?” Scott responded, “Well, it depends on what you mean by recent. There have been a number of changes to our network over the past 12 months as the result of security and performance assessments performed over a year ago.” “I’ll need to see an updated network diagram,” Bill replied. “The more comprehensive, the better… oh… and also configuration data for your fire- walls, routers, and other network access points.” Scott shuffled around some paperwork in a folder from his desk and placed the diagram displayed in Exhibit 4 in front of the investigator. 23

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS “We made a few significant changes to the network architecture we were operating with a year ago,” stated Scott. “We dispensed with the remote access/dial-up server and have converted all of our remote users over to VPN. We also instituted an LDAP server that is integrated with our Active Directory environment to authenticate partner users to the partner extranet, 24 Exhibit 4. Updated Network Diagram IDS Stateful Packet Filtering Firewall VPN Server SMTP Gateway (Anti-Virus and Content Filtering) Web Content Filtering Gateway LAN (172.30.0.0/16) INTERNET ISP-Managed Router Application Proxy Firewall (Primary (Public) DNS Server) Partner Network Connection Partner Net (Router ACLs) Server Network (Fully Switched) DNS Server(s) (Primary and Secondary) Active Directory/ Domain Controller (and Backup Domain Controllers) Corporate Mail Server IDS Database Servers Corporate LAN (Switched to the Desktop) Clients, Printers, etc. (500 nodes) QA/Development LAN (Fully Switched) Clients Development Servers (UNIX/NT) Syslog Server IDS Web Farm Internet DMZ Load Balancing Device IDS Extranet DMZ Web-referenced Database Servers Partner Extranet LDAP Server Web Cache Content Mgt. DMZ (172.30.1.0/29) .245 204.70.10.240/29 (Publicly Addressed IP Network) .246 .241 .244 204.70.10.224/28 (Publicly Addressed IP Network) .228, .229, .230 .208 .193 .194, .195 204.70.10.192/28 (Publicly Addressed IP Network) .224 204.70.10.160/ 28 (Publicly Addressed IP Network) .221 204.70.10.208/28 (Publicly Addressed IP Network) .209 172.30.0.1 DB Replication

Case Study in Subversion Exhibit 5. Stateful Packet Filtering Firewall (Perimeter 1) Permit/ Deny Source Destination Protocol/Port Permit Any (0.0.0.0) Permit Any (0.0.0.0) Permit Any (0.0.0.0) Permit Partnernet (192.168.10.0) Permit Internet Web servers (204.70.10.228, 229, 230) Permit Extranet Web servers (204.70.10.194, 195) Permit Database DMZ (204.70.10.160/28) Permit Corporate LAN (204.70.10.209) Permit Corporate LAN (204.70.10.209) Permit Public network (204.70.10.0/24) Permit Corporate LAN (204.70.10.209) Deny Any (0.0.0.0) Internet Web servers (204.70.10.228, 229, 230) Mail scanning gateway (204.70.10.209)a Application proxy firewall (204.70.10.209) Extranet Web servers (204.70.10.194, 195) Database DMZ (204.70.10.160/28) Database DMZ (204.70.10.160/28) Corporate database servers (204.70.10.210, 211) Internet Web servers (204.70.10.228, 229, 230) Extranet Web servers (204.70.10.194, 195) Corporate syslog server (204.70.10.209) Any (0.0.0.0) Any (0.0.0.0) TCP 80 (HTTP) TCP 25 (SMTP) TCP 53, UDP 53 (DNS) TCP 80, TCP 443 (HTTPS) TCP 1433 (SQL) TCP 1433 (SQL) TCP 1433 (SQL) TCP 8080 (Web development), TCP 21 (FTP) TCP 8080 (Web development), TCP 21 (FTP) UDP Port 514 (syslog) Any port Default deny (logging) a Network Address Translation (NAT) is being performed at the application proxy firewall; this is reflected in the source and destination addresses for LAN hosts on the Stateful Packet Filtering firewall. implemented a Web cache, and migrated our content scanning servers to a DMZ off of the application proxy firewall. Finally, we established a set of Web-accessible database servers on a DMZ off of the stateful firewall that synchronizes with select databases on the corporate LAN.” Scott paused for breath, “I think that covers everything — I’ll have to follow up with the router and firewall configuration data.” An hour later, Scott delivered the requested configuration information to the investigator. The Internet router configuration was reasonably hard ened with access control lists that controlled remote access; a review of the firewall configuration information revealed the information in Exhibits 5 through 7. Bill’s team was afforded access to Dalmedica’s systems and network, and any resources — intrusion detection systems, firewall, system and 25

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Exhibit 6. Application Proxy Firewall (Perimeter 2) Permit/ Deny Source Destination Protocol/Port Permit Any (0.0.0.0) Content management DMZ (172.30.1.0/29) TCP 80 (HTTP), TCP 25 (SMTP) Permit Partner network (192.168.10.0/24) Corporate LAN (172.30.0.0/16) TCP 21 (FTP) Permit Database DMZ (204.70.10.160/28) Corporate database servers (172.30.2.210, 211) TCP 1433 (SQL) Permit Public network (204.70.10.0/24) Corporate syslog server (172.30.2.250) UDP port 514 (syslog) Permit Content management DMZ (172.30.1.0/29) Corporate syslog server (172.30.2.250) UDP port 514 (syslog) Permit Corporate LAN (172.30.0.0/16) Application proxy firewall (204.70.10.209, 172.30.2.254) TCP 22 (SSH) Permit Corporate LAN (172.30.0.0/16) Internet Web servers (204.70.10.228, 229, 230) TCP 8080 (Web development), TCP 21 (FTP) Permit Corporate LAN (172.30.0.0/16) Extranet Web servers (204.70.10.194, 195) TCP 8080 (Web development), TCP 21 (FTP) Permit Corporate LAN (172.30.0.0/16) Public network (204.70.10.0/24) TCP 22 (SSH), TCP 69 (TFTP), UDP 161, 162 (SNMP) Permit Corporate LAN (172.30.0.0/16) Any (0.0.0.0) TCP 22 (SSH), TCP 25 (SMTP), TCP 80 (HTTP), TCP 443, 563 (SSL), TCP 20, 21 (FTP), TCP 110 (POP3), TCP 21 (Telnet), TCP 119 (NNTP), TCP 53 (DNS); and UDP 53 (DNS), TCP 1433 (SQL) Deny Any (0.0.0.0) Any (0.0.0.0) Default deny (logging) device log files, system/platform inventories, etc. — that might assist them in piecing together what had occurred. As additional data about the nature of the security breach came to light and the scope of the investigation broadened, Bill kept Scott and Dalmedica’s security incident handling team informed. At the end of the first week, as the investigation unfolded, a meet ing was called to give the investigation team a chance to turn over some of their initial findings. *** 26

Case Study in Subversion Exhibit 7. Application Proxy Firewall (NAT) Translate Source Destination To Protocol/Port Many-to-one Corporate LAN Any (0.0.0.0) NAT Trans (172.30.0.0/16) Many-to-one Any (0.0.0.0) Corporate LAN NAT Trans (172.30.0.0/16) Many-to-one Any (0.0.0.0) Content NAT Trans management DMZ (172.30.1.0/29) One-to-one Any (0.0.0.0) Corporate NAT Trans database servers (204.70.10.210, 211) One-to-one Any (0.0.0.0) Mail scanning NAT Trans gateway (204.70.10.209) One-to-one Public network Corporate syslog NAT Trans (204.70.10.0/24) server (204.70.10.209) Firewall’s outside interface (204.70.10.209) Firewall’s inside interface (172.30.2.254) Firewall’s content management interface (172.30.1.1) Corporate database servers (172.30.2.210, 211) Mail scanning gateway (172.30.1.5) Corporate syslog server (172.30.2.250) <Any> <Any> <Any> TCP 1526 (Oracle/SQL) TCP 25 (SMTP) UDP 514 (syslog) “OK, everyone, let’s get started,” Bill announced in an authoritative voice. Because a select portion of Dalmedica’s upper management team was present for the meeting, he had taken the time to prepare an overhead presentation on their behalf — aimed at a simple explanation of a complex turn of events. As he spoke, he clicked the remote and the projector whirred into action. “I thought it might be useful to start by reviewing some of the tools that have been employed in the investigation to date, take a look at our initial technical findings, and then discuss some suggested ways forward for the investigation.” “This slide (Exhibit 8) overviews some of the tools and techniques that have been utilized to preserve the technical evidence we’ve uncovered,” stated Bill. • Use of external binaries to analyze systems (based on platform inventory). • Use of dedicated forensics workstation (for analysis and reporting). • All evidence secured in a secure room and locker. • Tools: File viewers, Unerase tools, search tools, drive imaging software, forensic programs. Exhibit 8. Investigative and Evidentiary Techniques 27

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS • Confirmed initial findings. • Working with ISP to parse through relevant log file data. • Firewall log files and router log files confirm DNS denial-of-service packet flooding. • Evidence of connection laundering — DNS reverse lookups on source addresses reveal some interesting system and domain names. Exhibit 9. DNS Denial-of-Service • There is evidence of code having been compiled on the system that relates to two processes running on the server (.o, .c files, etc.). • Server processes appear (from memory dumps, connection attempts, and hex analysis) to be a custom file transfer application. • Log files were excerpted using a log file editing tool found on the system in a/tmp directory. • Ex-employee account was implicated (judging by shell history files). • The origin and purpose of the two secondary accounts are uncertain. Exhibit 10. Source Code Control System • Confirmed compromised by a Trojan backdoor — RWWWShell. • System was likely infected via e-mail — initial inspection of Outlook seems to confirm this (.pst file inspection). • Working with e-mail administrator to retrieve SMTP logs and analyzing e-mail header data. • Continuing investigation to see if other systems are affected. Exhibit 11. Windows (SCCS) Management Client “So, let’s cut to the chase — what did we find?” Bill sighed. “Well, as sus pected, files on the Source Code Control System have been tampered with, and…. well, we have found evidence that other systems were involved. Let’s run through this — system-by-system — and analyze the initial findings.” Bill clicked through the next series of slides (see Exhibits 9 through 13). Bill wrapped his presentation, saying “In conclusion, I would strongly recommend that we continue and expand the investigation, and that Dalmedica give consideration to working with us in making an initial con tact with law enforcement. We believe that if we continue the investigation we may find other and remote systems that were involved, which will assist us in understanding the motive for the activity and, perhaps, lead to the perpetrators.” 28

Case Study in Subversion • There are indications that other UNIX development systems are involved. • On some of these systems, .rhosts or hosts.equiv files may have been updated (still under investigation). • A Linux system was uncovered that has a trust relationship with the SCCS server that appears to be implicated — running the same two foreign processes as the SCCS server with a backdoor listener. • This information was uncovered via a manual audit of the system (original drive image preserved) using hex editors, string searches, and forensic tools. • Investigation continues. Exhibit 12. UNIX Development System • IDS activity revealed the following preliminary information: – Internet Web servers have been probed for CGI vulnerabilities using specific query strings. – Database servers on the corporate LAN have also been probed. – Partnernet IDS picked up some of the DNS denial-of-service activity and some activity to and from the corporate LAN. • IDS systems were deluged on the day of the DNS denial-of-service, impacting packet capture. Exhibit 13. Other Avenues of Investigation Bill was interrupted — somewhere at the back of the room one of the grey business heads bobbed up, “How did this happen…?” Read on… Notes 1. Refer to the “Security” section of Chapter 9 for an explanation of split-level DNS. 2. Note that, generally, a DNS-based denial-of-service attack leverages DNS responses to effect an attack against a target network, using IP spoofing in conjunction with DNS lookups. Refer to Chapter 9 for reference. 3. Internet recursion is discussed in some detail in Chapter 9. 29

Chapter 3 Know Your Opponent Felix Lindner This chapter gives you an introduction to the motivation of your opponent. Because motivation is the engine that drives any action, this is the key to defense. The Federal Bureau of Investigation (FBI) and other advanced law enforcement organizations around the world use profiling to describe and categorize criminal behavior. This leads to better understanding of threats and techniques, which facilitates effective defense. It is essential to know what happens behind the front lines, to know where the tools and people come from, and to be able to make judgments about future developments. The same principles that apply in law enforcement and the military should help you defend your systems. Taking the time to understand the history of hacking and why your opponent is doing what he or she is doing will pay off. The typical profile, fueled by the media and public opinion, is the following: A young boy, with greasy blond hair, is sitting in a dark room. The room is illuminated only by the luminescence of the C64’s 40-character screen. Taking another long drag from his Benson and Hedges cigarette, the weary system cracker telnets to the next faceless “.mil” site on his hit list. “guest — guest,” “root — root,” and “system — manager” all fail. No mat ter. He has all night. He pencils the host off of his list and tiredly types in the next potential victim…1 This picture was fed to the public for a long time. Now the media has changed its view on “hackers,” constructing a more nefarious image, which can of course be better used for exciting news, reports, and articles. But the image is still a stereotype. This chapter will try to give the reader a more differentiated view. Terminology A longstanding debate exists in the computer security field about the correct terminology to use to describe an attacker. Bob Woods wrote a Newsbytes editorial in 19962 to explain why the news media uses the word hacker even 0-8493-0888-7/04/$0.00+$1.50 © 2004 by CRC Press LLC 31

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS though many people send them corrections every time they do it. The sum mary of this editorial is: “The public knows them as hackers — we know that they are more correctly referred to as crackers.” I agree with this state ment. To circumvent the naming issues here while discussing different motivations and backgrounds, this chapter will cast some light on common terms first. At one point in time, a hacker was someone who enjoyed learning details of programming languages, computer systems, or algorithms and pre ferred the actual process of writing programs rather than planning and designing them. He appreciated good hacks from other hackers and was commonly known to his peers as an expert on specific topics. In short, you could think of people similar to those who initially wrote the Linux kernel. The New Hacker’s Dictionary3 was started in 1975 as the jargon-1 text file and therefore covers ages of computer and Internet history, covering the type of hackers the media refers to in the short section “Crackers, Phreaks, and Lamers.” It dates this culture back to the late 1980s, when some people used MS-DOS-based systems to run “pirate” bulletin boards and states that the jargon is heavily influenced by skateboard lingo and underground-rock slang. I would assume this describes what is in most readers’ minds when they think of hackers. Script Kiddy People calling themselves “real hackers” invented the term script kiddy. Compared to script kiddies, the inventors of this name were highly skilled in the techniques of computing environments and how to use these to gain unauthorized access. Script kiddies in contrast are described as people who just run scripts that they obtain from hackers. This term spread very fast. Today’s script kiddies spend most of their time in IRC — Internet Relay Chat — and trade information and 0-day exploits. They often have no par ticular interest in the problems and challenges of computer security. The targets of their attacks are not carefully selected but rather are systems that happen to be vulnerable to the particular exploit they have at hand. But you should not underestimate them. Script kiddies are by far the biggest group of attackers you are facing. They have an internal social structure and are trained in obtaining dangerous information fast. Defend ing yourself against the average script kiddy is not difficult, but you have to keep in mind that script kiddies will often have access to a new exploit months before you know this exploit exists. Script kiddies are criminals. The problem is that they do not see them selves as such. If asked, they tell you the crime they commit is like stealing chocolate in the supermarket. They feel that hacking systems is more like collecting baseball cards than attacking the heart of someone else’s busi ness. The 17-year-old “Mafiaboy,” who became famous by being arrested 32

Know Your Opponent for his distributed denial-of-service attacks on popular Web sites such as Amazon.com, eBay, Yahoo, and Cable News Network (CNN), was seen by his peers in IRC as a script kiddy. After he performed the attacks, he went straight into IRC and told everyone what he had just done. This fact illus trates that, despite the fact that he committed a crime and his action resulted in a substantial loss in money for the victims, he did not realize that he had committed a crime and was at risk of prosecution. If he had realized that he was now a criminal, would he go into IRC and tell everyone? Probably not. Another angle to look at in this particular case is the motiva tion. Was this boy interested in blackmailing these companies? Or did he work for a competitor who was interested in taking these sites down? Did he promote a particular security product that prevented such attacks? None of these motivations seems to fit. To the best of the public’s know ledge, he did it for fun and simply “because I could do it.” This underlines the basic issue: for most script kiddies, there is no real difference between killing people or monsters in the latest ego-shooter game or taking out computer systems that run a company’s business. Cracker Most security professionals today refer to the average attacker as a cracker. This became a generic term for attackers with medium-level skills and no noticeable ethical boundaries. As with all of these terms, “cracker” is not closely defined but rather changes its meaning from time to time. As the reader will see in the historical background section, even the term cracker once described a different type of person and had less negative images connected to it. One of the major differences between script kiddies and crackers is that crackers actually understand some of the technology behind their doings. Their tools do not have to be much more advanced than those of script kid- dies, but a cracker usually knows how to use these tools and all possible options. Crackers understand why a particular tool is not working in some cases, and their attacks are less noisy than those of script kiddies. But crackers are not limited to the tools they use. They extend the process of system penetration to the degree where every bit of information is used to perform the task. Once they have broken into a computer, crackers will collect all data that could be useful in later attacks on other systems. This includes password files with encrypted or hashed passwords that are cracked on their home system or yet another computer broken into some time ago. They also use social engineering techniques if they are more effective against a particular target than a technical attack. In contrast, script kiddies would never call the company they are attacking. The cracker is interested in taking over as many systems as possible. The way the attack is performed does not matter. If a simple attack is possi ble, a cracker would seldom choose another more elegant attack vector. 33

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS The compromised systems are later used as a platform for new attacks, to crack passwords, or as so-called zombie hosts for distributed denial-of-service attacks. Crackers are aware of the fact that their doings are illegal in most countries. They take care about the connection that can be seen from the target system or network. Redirectors and proxies are often used to hide their digital tracks. They also take care of log files and make heavy use of so-called rootkits that hide the backdoors they leave behind. Crackers prefer high-profile targets. Although script kiddies may not even notice the purpose of the target they attack, crackers focus their target selection on certain criteria. If the target seems to have a large amount of processing power, it can be used for brute-force cracking. If the system has a high bandwidth connection to the Internet, it is a good platform for further attacks. Sometimes, targets are chosen because of their purpose. For example, some cracker groups focus on high-profile Web servers and deface Web pages. This increases their reputation on the cracker scene, which in turn leads to more connections to other crackers. The more con nections the cracker has, the more exploit code and information he can obtain. The cracking society has several parallels to mafia organizations, in this sense. White Hat Hacker The perpetual debate about naming forced the security community to invent a new system. It refers to people as Black Hat, White Hat, or Gray Hat hackers. Black Hat stands for the bad guys, White Hat stands for the good guys, and Gray Hat describes people sitting in between. There are many speculations but no proven relations between this terminology and a Linux distributor called Red Hat. The source of this system is early Western movies. Good guys wore white hats, whereas bad guys always had dirty black hats. This color-coded termi nology made it easy for the audience to distinguish between the good guy and the bad guy. Unfortunately, the world is not black and white. People referring to themselves as White Hat hackers are interested in computer security for a completely different reason from those that moti vate other hackers. They think this field is interesting because it changes every day. They see the need to protect the public by actively discovering security holes in software and making the public aware of this issue. White Hats work together with the vendors of particular software to solve the issue and make the digital world more secure. Even if the vendor takes several months to fix the hole, the White Hat would not publish the information before the vendor does. Some White Hats see themselves as knights in shiny silver armor protecting the innocent from the bad guys. White Hats would never use their knowledge to break into a system they are not allowed to. 34

Know Your Opponent Despite the fact that most people think that the best protection is developed by people actually breaking into systems, some of the most advanced techniques for protection are developed by White Hats. Because their background is often one of higher education and they are aware of the additional needs a protection system has to fulfill — such as stability, portability, and simplified management — White Hats are often the better developers or consultants. Black Hat Hacker In contrast to a White Hat hacker, a Black Hat is in general put into the “bad guy” corner. But Black Hats would prefer to define themselves as “not White Hat” and never as “bad guys,” because from their point of view, the vendors of insecure software and the script kiddies and crackers are the bad guys. The technical knowledge of the Black Hat is at a level comparable to that of a White Hat, although the focus is a little different. Where a White Hat has an interest in general software development issues and algorithms that can be applied globally, the Black Hat is often a better assembly program mer and knows more about processor architecture and different target systems. In general, most Black Hats seem to know a wider range of tech nologies in today’s computing environments than White Hats do, whereas White Hats may have a better understanding of algorithms. The Black Hat usually scorns an insecure network and the administrator who is responsible for the security of that network. When he or she reports security issues to a vendor, this is done in a manner that imparts information sufficient for him or her to fix the problem. The Black Hat does not care if the vendor cannot understand the issue according to the provided information. In such a case, or if the vendor does not observe the timelines given by the Black Hat, the Black Hat will disclose the information completely to the outside world — including exploit code — and will not necessarily care about the risks. Some Black Hats do not even care about the general policies connected to full disclosure (see the section on ethics in this chapter). There is already a trend in the Black Hat community to keep information rather than disclose it. Hacktivism The word hacktivism is a combination of hacking and activism. A hack tivist is someone who uses system penetration to propagate a political, social, or religious message. The targets of such individuals are mostly high profile Web server environments where as many people as possible see their message. The level of such a hacktivist is often that of the script kiddy. Because the whole exercise is done to promote the message and not to attack the system, the process of penetration itself is not of particular interest to the 35

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS hacktivist. This holds true for most hacktivism. Lately, especially in the conflicts between the United States and China,4 hacktivism obtained a new face. Hacker groups or individuals ranging from script kiddies and crackers to Black Hats started attacking and defacing Chinese Web sites. The Web pages of political organizations in Afghanistan became targets for hundreds of attackers after the terrorist attacks on the World Trade Center and Pentagon in September, 2001. Hacktivism of this sort is likely to be per formed in a professional manner. The attackers sometimes build teams and attack not only the primary target but also the perimeter devices in its net work to achieve maximum impact. Although many hacker groups have released statements saying that they do not support this kind of hacktivism and have asked the hacker community not to use the worldwide data networks as a place of war, I assume this kind of hacktivism will grow in the future. The cracker groups penetrating systems nearly every day are able to outperform most system administrators of propaganda Web sites, and they know it. Professional Attackers Conflicts such as the ones discussed above do not only interest patriotic crackers. According to military sources, every nation has by now at least a small military department that is tasked with information warfare. Most secret services around the world have increased the number of informa tion security professionals they employ and leverage the fact that many systems can be reached remotely. Agencies and the military in every nation are spending money to build up and train their professional attackers. Although the defense of com puter systems has been on the task list for many years now, the attack strategies are relatively new. The huge difference between all other groups and the professional group is the amount of money and organizational back-end support that is available. These groups have laboratories and everyday training. They do not have to be the most expert hackers in the world (although some may be); because there is money, there is always some experienced Black Hat who is willing to train them. The reader will probably doubt the statements above because not much is known about such groups or the action they take. But this is exactly how it is supposed to work. Spy networks such as the one known as Echelon have been in place for a long time now, and still nobody really knows what they do and do not do. The same applies to information warfare and how much of daily business operations is actually subjected to espionage of one form or another. The truth is, one can only estimate from past experi ences with other groups such as the huge cryptography teams working at the National Security Agency, with regard to how much energy is put into the information warfare groups of the leading agencies around the world. 36

Know Your Opponent History It is very difficult to provide a historic view of hackers as a whole. Today’s hackers — in the sense of Black Hats or White Hats — are the result of several different groups and movements from five to thirty years ago. I will describe some of the sources and give pointers to what kind of groups resulted, but readers should exercise their own judgment in this area. The reader must be aware of the fact that every individual has differ ent reasons and driving forces behind his or her doings. By pointing out some of the sources hackers evolved from, the readers can match these sources to the people they encounter in the wild and make their own deci sions. When talking about anatomies of hacks, the reader will find some of this background information useful. Behavior becomes more predictable when the history of the individual’s environment is taken into consider ation — and this does not require knowing the individual. Sometimes when dealing with permanent attacks on systems that we are supposed to protect, we have to remember that anyone who owns an IBM personal computer (PC) or its successors has perhaps committed a com puter crime at least once. The crimes you have probably committed are: • Violation of the copyright laws that apply in your country. I am sure that the reader has at least one commercial software product on his hard drive that is not purchased or for which he or she is not holding a valid license. Are these several shareware programs with run-out evaluation timeframes? Guilty. • Violation of data integrity laws, if applicable in your country. Did you ever download a crack or a patch that originated from a source other than the vendor itself? Did you apply this patch? Guilty. • Committing the crime of document forgery. The last time you down loaded a piece of software, what name did you enter in the registra tion form and what e-mail address? Not your own? Guilty. I could list more of these, but I think you get the picture. Most of these crimes are “normal” in our digital world, and nobody thinks about it — in some countries it is the same with speed limits. All we have to remember is the fact that putting someone in the Black Hat corner or allowing that person to go to the White Hat corner is not dependent on whether the per son committed a crime according to the law but more or less depends on one’s point of view. Computer Industry and Campus The term hacker itself and many references come from the computer cen ters at universities and computer industry laboratories. Many scientists, assistants, system managers, teachers, and students are hackers in the original meaning of the word. Many of them are also interested in computer security and society issues. 37

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Dorothy E. Denning (working at Digital Equipment Corp. Systems Research Center) in Phreak Magazine, Volume 3, Issue 32, File #3 of 12, wrote on the subject of hackers and their motivations and ethics: The ethic includes two key principles that were formulated in the early days of the AI Lab at MIT: “Access to computers — and anything which might teach you something about the way the world works — should be unlimited and total,” and “All information should be free.” Beside the fact that Denning is referring to an ethic here, it is no surprise that a well-known and respected name (the Massachusetts Institute of Technology [MIT]) is mentioned. The skill level at such institutes is under standably high, the systems are available to students, and the general trust between people is high. Every student at a technically oriented university has access to at least three different operating systems. Superuser access is usually granted to interested students. In the professional security environment of today, the saying “like a university” refers to computer sys tems with lax security and without the most basic protection. The computer industry laboratories, the information technology sections of universities, and the appropriate sections of the Department of Defense developed a network based on a protocol family of a Transport Control Protocol, a User Datagram Protocol, and an Internet Protocol, today known as the Internet. The scientific members applied their rules of trust worthy peers, and the military members applied their rules of verified trustworthiness before being allowed to join. People invented and imple mented services to give out information as freely and as simply as possi ble. The results are services such as finger, Telnet, FTP, HTTP, or the World Wide Web. The same organizations developed operating systems such as UNIX or contributed essential parts. Although VMS and UNIX introduced the concept of processes that run parallel but have their own protected memory ranges, the access levels for human users could not be more simple: You are the superuser (your user ID is 0), or you are not. The primary goal was function ality and powerful tools. Portability was also high on the list. Every user of today’s UNIX will agree that these goals were reached. Tools developed for UNIX — such as the various shells, Perl or Sendmail — are all very powerful. They were designed by programmers for programmers. But powerful func tionality often has the drawback of complexity, which in turn often leads to bugs in software or at least unexpected behavior. Unexpected behavior is all an attacker needs to gain unauthorized access. I use and love UNIX — but I know what price the power of UNIX sometimes costs. UNIX “wizards” often tell you that they broke into systems for various reasons and refer to themselves as hackers — but they are not your daily enemy. So what is the difference? The first one is that these wizards refer 38

Know Your Opponent to themselves as hackers in the original sense of the word. The second point is that the number of times they broke into systems is probably less than ten. My experience is that they have done this every time for a reason able reason (such as the admin of a system being on vacation) and some times for fun. The centers of intelligence and excellence of our information society are part of the development that created Black Hat hackers. They gave them the technology and methodology as discussed in the paragraph on hacker ethics. System Administration System administrators and operators did their part in the development of Black Hat hackers. The reader may disagree with that statement and indeed, their influence is perhaps the smallest in the whole scenario, but the overall application of the security concepts mentioned above introduced the position of an omnipotent person — the superuser — and many readers may agree that they have misused the technical permissions they were given for their day-to day work at least once. Maybe it was the reading of someone else’s e-mail to the sweet secretary on the first floor or the creation of a private Web site on the company’s network. Ever killed a user’s shell? It could be a misuse of permissions given. Whoever thinks that his superuser would never do such a thing: take a look at the text series “The Bastard Operator from Hell.”5 Although most system managers never become Black Hats, some do. Home Computers The introduction of home computers in large numbers in the 1980s was prob ably the beginning of the era of premature attackers. Computers such as the Commodore C64, Amiga 500, Atari ST, and IBM PCs were introduced into the bedrooms of teenagers. These computers had several advantages over other toys such as game consoles: you could program them yourself, and you were encouraged to do just that. But most customers bought their software at the local dealer. This was mostly for the system’s game capabilities, although the gaming capabilities of the IBM PC, at that time, were very limited. You can spend a huge amount of time on a single computer game, but at some point in time, even this is no longer interesting. Then, you either buy a new game or start programming and playing around with your com puter. This generation was able to accumulate an extraordinary level of knowledge due to the following: • The computer was at home. You could come back from school or work and spend your time using it until after midnight without having to ask for processing time or pay anything except power, and it was in your home environment. This led to an average amount of time spent on these relatively simple computers that was surprisingly high. 39

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS • The process was reproducible. Unless you were playing with the frequency of your monitor or the timing of your central processing unit (CPU), you could do everything over and over again until you found out what you wanted to do. Things changed in random access memory until you decided to turn the system off — then, everything was back to square one. You do not break anything when changing bytes in memory. This is a powerful aspect of hacking and programming development. In contrast to the real world and for example, chemistry, you can learn and develop knowledge in information technology to a certain level by trial- and-error methods. Do not try to learn how to create nitroglycerin the same way. The trial-and-error method was supported by other factors. Documenta tion was expensive and not always available. In fact, most interesting parts of normal operating system design, file formats and so on, were docu mented in the UNIX environment only. The home computer vendors charged for every bit of information. Some of them even tried to prevent information from being known so that they could sell their development packages. What these vendors failed to notice was the need for software and the need for programmers. Home Computers: Commercial Software Commercial software was for a long time the only software available for home computers — and it was expensive. The price of a computer game today is still as high as it was in the beginning, and most teenagers would simply not spend so much money on a game. The result: games were and are copied. In contrast to the real world, you can clone data in the computer world. Once this process is complete, the original data is unchanged, but you have another set of data that is 100 percent identical to the first one. It is hard to imagine — even for lawyers and other adults — that this is a crimi nal act. How can this be bad? Nothing is damaged, right? Nobody is hurt. The question in the heads of the people who were hurt — the people whose income was affected by the decreasing sales numbers — was differ ent: how can we prevent this from happening? The introduction of law enforcement into the game did not help much to prevent teenagers from copying software. And parents had problems in understanding what their kids were doing or had the same attitude towards copyrights and prices for software that the kids did. With the growing number of home computer users, police could no longer check every lead about possible software piracy. Therefore, the software industry introduced copy protection mech anisms. First, numbers had to be entered into the game before you could play, and these numbers were on the packing or on a code table that came with your game. These protections could be circumvented with publicly 40

Know Your Opponent accessible photocopying technology — just copy the code card. Later, soft ware developers became better at the game and introduced bad-sector checks, key disks, manual checks, and many exotic ways of making sure the software was licensed. None of these remained uncracked. The term “cracking” software refers to the process of reverse-engineer ing the software and then changing the code to disable the protection. What you need is: • The software and optionally one valid key. • A so-called debugger, memory editor, or in-circuit emulator (ICE). Although the way of doing things is completely different for each of these three, the effect remains the same. You can stop the program in question at any time, examine the memory (what changed — what did not) or run the program step by step, where a step is one CPU instruction at the time. This is the detail level on which you control every tic in your computer. • A certain level of knowledge about the platform you are working on, your CPU, and a list of supplementary chips inside your computer. • Later, as it became available, special hardware. Introduced in 1985 by Apple for its Apple II computer, the “Apple II Action Replay” was an external hardware debugger. The “Amiga Action Replay” by Datel (http://www.datel.co.uk/) was a full-blown cheat extension card for the Amiga 500 and could be used for cracking as well. Talented people worked alone or in groups on newly released games and protection mechanisms and developed small changes for these programs to disable their protection. The process of searching and finding such a protection is sometimes very time-intensive and — depending on the level of the programmer who created it — the protection could be very compli cated to break. Sometimes, the protection itself was protected, and the game stopped working in the middle because the protection part was altered and so on. The time and knowledge invested in such a change (called a crack) is much more than the reader may assume. The result was a program that changed the original binary executable file or a new version of this executable without protection. Imagine the amount of time you need to crack a game and that the result is a 10-byte patch. Your achievement is not represented in an appropriate way. That is where the so-called INTRO came into play. First, the cracker changed some graphic or text string in the game itself to have his synonym displayed as to who he is and that he cracked the game. Later, the programming skill developed on the home computers was applied to a DEMO — a piece of noninteractive software that looks a little bit like an MTV video clip: high-end, real-time computer graphics, great background artist work, and terrific sprites (moving, often layered, bitmaps), fantastic music playing in the background, and 100 percent 41

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS adjusted to the graphics. Now, members of a group could use all their abilities to show not only how good they are at cracking software but could introduce themselves in an appropriate way to the world. New skills were needed: graphic artists (GFX’rs), music composers, and the programmer for the engine — the software running the whole thing. New software was needed as well: sound composers written by hackers were for a long time the state of the art in computer music on home computers. Competitions started to determine who wrote the best DEMO, and soon the scene developed an independent existence with DEMOs written for fun or for conventions such as the Assembly (http://www.assembly.org/). The DEMO scene is still active and has moved to other operating systems or is still using the Amiga but is very much separated from the cracking scene now. Demo coders and artists with their work can be found at http://gfxzone.planet-d.net/and http://www.scene.org/. Home Computers: The BBS Although there is much to tell about cracking game software, another development dates back to the late 1970s. Bulletin Board Systems or BBSs — sometime called mailboxes — were the first widely used data transfer points. As usual, the industry found out that their need for communication could not be fulfilled by normal means of communication such as snail mail. Sending out software patches on tapes was not very effective and required a lot of human intervention. Direct access from one computer into another was needed. The solutions were serial connection methods. The range is wide and includes UNIX-to-UNIX Copy (UUCP) and Serial Line Internet Protocol (SLIP) applications on UNIX systems as well as XMODEM, YMODEM, and ZMODEM protocols mainly used with PC clones. System operators now could connect from one computer into another using a serial line. By mod ulating the signals used between these two hosts into sound, you could transfer data over a phone line. The device to do this was called a modula tor/demodulator— a modem. The possibility of using publicly available phone systems to connect two computers introduced a new era. Although at first the connections were performed system-to-system for maintenance or operation, soon cen tral points of communication came into existence. These systems had more free hard drive space than others did and could therefore hold more data. The BBS was born. As often observed, industrial applications slowly make their way into homes. First, system operators had modems at home with which to con nect to work. Then, they set up their own BBS and ran it on a secondary line. When this development met with the evolution of IBM PC clones and Amiga systems, private BBSs mushroomed. They were used to exchange 42

Know Your Opponent tools, papers, and of course, cracks for games. All individuals who counted themselves as part of the hacker or cracker movement had to have at least one home BBS system where they spent most of their online time. Cracker groups used several BBSs but had designated HQ BBS systems — some times not really belonging to them but cracked into. For a current perspec tive: think of it as a network of Web sites and their mirrors. BBSs had several advantages: • There was no rocket science involved in setting them up. In fact, most BBS systems were simple MS-DOS-based programs taking advantage of the simple OS-to-hardware situation. User authentica tion and access to different file system parts was granted by some kind of proprietary implementation — often just flat files protected by a username and password. • They were cheap. The most expensive part of each system was the modem and hard drive. The individuals running the BBS did not pay the phone bill, because the caller paid (if he or she paid at all — see the next section). • You could get in contact with people. BBSs usually employed several board systems and were later connected to each other so people could swap files, software, and messages across BBS boundaries. Although commercial BBSs did not really change a lot over time, private systems became separated. Three groups evolved: 1. The first group consisted of “normal” file BBSs run by private indi viduals who did not interfere with any law. They just distributed freeware and shareware programs, pictures, text files, and messages. They often had uplinks to the FIDO net, which still has approximately 30,000 systems worldwide and uses direct modem connections and border remailers to exchange e-mail with the TCP/IP Internet via UUCP. The private boxes disappeared first when private Web pages became available because their operation was very expensive and work intensive compared to Web page maintenance. 2. The second group of BBS systems consisted of semicommercial or sponsored systems. The primary intent of these was to facilitate chat and communication. People running these systems all over the world have either moved over to Internet-based chat systems, such as IRC, or decided to stay in the modem-based area a little longer. Some bigger companies figured that this was a good opportunity to do some marketing and started sponsoring these modem systems. Pubs and clubs used the access and some old PC hardware to promote them and encourage customers to use them. One example is the still-existing modem system in several German cities, which is sponsored primarily by Marlboro. 43

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS 3. The third group leads us back to the history of hacking: underground boxes. These were used to exchange illegal or semilegal contents. Because most normal BBS sysops (system operator — the owner of the BBS) banned copyrighted software from their systems to stay out of jail, underground BBS dial-in numbers were kept secret to prevent law enforcement from discovering them. But the boxes not only served the purpose of exchanging cracks and commercial software. People communicated through these boxes. Before the underground boxes existed, hacking and cracking groups were limited to specific geographical areas and could only communicate to each other. Open BBSs were not safe enough, and public key encryption was not widely known. Using underground BBS systems, groups could com municate on fairly safe systems, publish their ideas in papers, and find other groups and new members. The first E-zines (electronic magazines) appeared and were distributed through the HQ boxes. By this time, a huge network of several thousand interconnected BBSs had developed. Each BBS had automatic or manual links to other BBSs and transferred files back and forth. It sometimes took several days for a file to reach the last BBS, but it worked fairly well. Although the traditional normal BBS did not enforce many regulations, and the commercial and chat-centric systems needed only behavior rules, the underground BBSs were very rigorous with their rules. Unknown hack ers did not get any information. You had to crack and hack a lot to get hold of a special phone number. Then, you could log in to the system with guest permissions. Only when an appropriate amount of interesting data was uploaded to the system, and you contributed “cool” stuff, ideas, or know ledge to the group, was your account promoted to user level. What you had to contribute depended very much on the focus and knowledge of the BBS members. The most desired material was more of the technical manual kind than commercial software or cracks. This changed when the Internet replaced most underground BBSs — but there are still some in use. Phone Systems The first targets of Black Hat hacking were telephone systems. When com puter connectivity was based on the availability of phone lines, and hack ers started using these connections to access computer systems they were not supposed to access, two issues arose: First, the use of a phone line was traceable. Everyone knows that ways to trace a connection back to its originating phone exist. Most readers will remember from Hollywood movies that the phone company needs consid erable time to perform such a trace. In the late 1970s and 1980s, these traces took more time than today. This means the attacker had to be con nected (or dialed-in) for this time to be traceable. But taking into account 44

Know Your Opponent that available transfer rates were between 1200 and 2400 baud, this was no protection — it took hours to perform a relatively simple task. Imagine how long you have to be connected to a computer system that you are not familiar with. As soon as you manage to get access to it, you have to find out what it is. If you do not know it and you do not have a manual or you could not even identify it, you have to use imagination, guess commands, and try to find out how it works, what you can do with it, and what its pur pose is. Even if you have a manual, you have to spend a long time finding the right commands and learning about the permission and access control mechanisms before you can leave at least a simple backdoor — because you do not want to go through the whole process of gaining access again. This all adds to the issue of being traceable. Now, if you could use some one else’s line or could be simply untraceable, then you could spend a lot more time hacking. The second issue is a profane one: money. Usage of phone lines is billed to the caller. If you wanted to hack someone’s computer and the only means of access besides breaking into the person’s office was by phone, you had to pay for the connection. This is traceable — but in the times we are referring to here, this was not the primary issue because most people did not realize they had been hacked. The issue was that you (or your parents) had to pay for a lot of long distance phone connections over a long time. This could easily increase a phone bill by several hun dred dollars. The only way around this was to use phone lines that were not exactly given to you by the phone company: those of your neighbors or unused ones. These two requirements led to an interesting and still existing move ment in the hacker scene: phreaks. The name comes from “freak” but with the f replaced by ph as in phone. The verb “phreaking” describes hacking phone systems. The desire to be untraceable and use phone lines other than yours was fulfilled by phreaks. First, connections to the neighbor’s phone line were made to use her line instead of yours. Because this person would often call the phone company very soon after her bill arrived, and the company would find the additional connection, this was not the best idea. The second step was to use unassigned lines. This often worked for a long time, but these lines had no phone number assigned and were not fully functional in many respects. The most successful way of phreaking was to actually hack the phone system core devices and configure the line you wanted to use yourself. This activity was known as “blue boxing” because often these lines terminated at a pirate BBS. Because the core devices could handle all kinds of phone services and special settings, some groups managed to have their BBS connected to a blue box that was actually accessible by a toll-free number. 45

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS Yet another way of more basic phreaking is probably well known. The public phones used to use dual tone multifrequency (DTMF) tones to report the coins inserted back to the core systems. These tones could be recorded and replayed every time the phreak wanted to place a long-distance call to a target computer. This is a very good example of technology that was developed and implemented to meet the needs of normal users and opera tors and not with security implications in mind. No phone company would use this method of payment approval today — but other methods in use are not necessarily more secure. The history of phreaking is very important for the general development of hacking. Phreaks are required to have good knowledge of all important protocols and connection types, as well as the functionality of the phone system they are attacking. On top of this, a lot of information is gained by social engineering, which requires the phreak to actually know the proce dures of daily business in the phone company. Phreaks have to call the right people to get the information required or have them configure the settings they are looking for. Phreaks have to use the right words to convince the victim that they are normal college students who simply need help. All these skills are not developed in one day. It takes a considerable amount of time to learn and to concentrate on the task. This shows an increase in dedication that was not seen before. Groups who worked together to gain additional knowledge and share or trade papers on phone systems evolved on pirate BBS systems. Many of the good phreaks could actually teach something to a normal phone company engineer because they spend most of their spare time learning the exotic behavior of the latest switchboard. Ethics and Full Disclosure The ethic includes two key principles that were formulated in the early days of the AI Lab at MIT: “Access to computers — and anything which might teach you something about the way the world works — should be unlimited and total,” and “All information should be free.” In the context in which these principles were formulated, the computers of interest were research machines and the information was software and systems information. The text Dorothy E. Denning was writing is about hackers breaking into systems and the fact that several contacts with hackers changed her point of view from “the bad guys” to a more differentiated angle. The reader might better understand the meaning and source of the quote above after the short excursion into the history of hacking presented in this chapter. But what are today’s hacker ethics? This question cannot be answered easily. Most White Hat hackers will tell you that their goal is to “find security issues and vulnerabilities in computer and information systems and make this information available to the public so everyone can protect them selves.” Their ethics prohibit the abuse of such information. White Hats 46

Know Your Opponent would not attack a computer system with their tools and knowledge simply because they do not like the person running the system. Is this an ethic? The same people tend to use their knowledge for commercial purposes. They found their own companies, publish their own products, or offer their services as consultants. If you find a major hole in — say, the most popular Web server, and you publish this information together with a detailed recipe on how to exploit it, is this ethical? If you then offer your service to the affected companies, is this ethical? Every reader has probably seen one or more TV reports where the TV people hired a “good hacker” to break into a high-profile target. The TV sta tion gains publicity and the hacker is now famous. Is that ethical? Last time I was watching such a show, the hacker not only showed his ability to hack an unpatched Internet Information Server at a bank but also provided extensive information about the book he had just published. On top of this, he offered a hot line to affected (scared) people, where he would give them recommendations on how to protect themselves. Of course, this hot line was not cheap. The TV reporter stressed the point that this guy could be a criminal and steal thousands of dollars from the bank, but instead was working with the TV channel to provide this information to the public. But if he would be a criminal and actually take the money, he would have to cover his tracks very carefully and make sure the money stayed in the account he transferred it to. This is not as simple as breaking into an unpatched Internet Information Server (IIS). And of course, being rich and famous because of the TV and the free promotion is way better than being rich and on the run because every law enforcement officer in the world is looking for you. Sometimes, Black Hats have ethics as well. These are less stable and you cannot put your finger on them, but they exist. Some Black Hats would never “trash” a system. Trashing refers to totally destroying a system installation to make forensics more difficult. This means, for the system administrator, that all data is lost and he has to recreate the whole system — hopefully from backups. Other Black Hats would leave digital business cards on the system to make the owner aware of the fact that the system is insecure. ************************6 * Y0uR 53(ur17y 5u(|<5 * * g3|\|3r1(hAx0r * ************************ Of course, the Black Hat committed a crime by breaking into the system in the first place, and the system owners cannot be sure that no backdoor has been left open to the attacker. They do not know whether the attacker used this system as the basis for new attacks or if he or she took over other systems in his or her network and just left this single business card. But 47

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS they are aware that their security has been broken. It is up to the company to decide on the next steps — including calling law enforcement and trying to track down, sue, and arrest the hacker. The business card he left does not protect him. On the other hand, the company is not forced to tell the public that it was hacked and can choose the consultant it feels most comfortable with to help find the problems and solve them. Is that more ethical? As you see, based on these two examples, the words “hacker ethics” no longer have any particular meaning. They more correctly describe what each and every hacker considers his or her ethics. Although it would deserve a chapter on its own, the debate about “full disclosure” falls under the ethics discussion. Full disclosure is seen as the contribution of the White Hat hacking community. Quoting from the fre quently asked questions (FAQs) of the most popular full disclosure mailing list, BugTraq:7 0.1.6 What is Full Disclosure? Full Disclosure is a security philosophy that believes: 1. A truly secure system must be able to withstand open review at all levels (e.g., protocol, source code, etc). 2. The details of security vulnerabilities should be available to ever yone. Benefits include: 1. A large number of individuals get to review the system for security weaknesses. 2. Vendors are pressured into providing security fixes quickly. 3. Programmers and system designers can learn from others’ mistakes. 4. Users can identify similar vulnerabilities on systems other than the original. Cons include: 1. At the same time you inform constructive people of security vulnera bilities, you also inform destructive people. The first paper I got hold of several years ago that could be seen as “full disclosure” was written by Dan Farmer and Wietse Venema in 1993. It is called “Improving the Security of Your Site by Breaking Into It” (http://www.fish.com) and gives UNIX system administrators a guide for simple hacking in UNIX environments. When this paper and the tool SATAN were released, many people blamed the authors for giving weapons to children by telling them how to hack the UNIX systems they try to protect. Both authors tried to give the reader a view on the things they are protecting by showing them the view of an attacker. Hacking and security texts (this one included) fall into the full disclosure discussion, because they provide poten tial attackers with information about what the defenders concentrate on. 48

Know Your Opponent Full disclosure and the process of how to publish such information are discussed very often, and no consensus has yet been reached. Rain Forest Puppy created a policy document that is recommended as a guideline for all kinds of hackers when dealing with newly found vulnerabilities. This policy — known as RFPolicy — can be found at http://www.wiretrip.net. It provides timeframe recommendations and rules of behavior for hackers and vendors. Many hackers observe this policy. But it is a recommendation — nothing else. Mailing lists such as BugTraq assume or trust the fact that hackers finding vulnerabilities will follow the line of this or a comparable policy. Belief in such policies is what makes full disclosure work. But what if other people do not follow the rules? What if they find vulnerabilities, are able to exploit them, and keep the information to themselves? A growing number of hackers think it is not a good idea to perform full disclosure in the way BugTraq contributors do. They argue that two differ ent types of information are distributed through the full disclosure lists. The first type is information about a potential security issue found in a product. This information does not include any way to exploit the security issue, yet. The person who posted this information just stumbled across something he or she thought could be a security issue or was at least not the way it should be. This information is useful for the system owners who run such a product because now they are aware of a potential issue. This information has another effect: Black Hats who develop exploits to actu ally use them now have the information that an issue exists and can look into the possibility of exploiting it. Now, the innocent message about a security issue leads to system administrators who know that an issue exists, a vendor that probably does not take the issue too seriously (because it is just theoretical), and a group of Black Hats who actually use this issue to penetrate systems. It is understandable that this outcome is not what was intended. The second type of information going to such lists is ready-to-run exploit code. This is an obvious danger because everyone — even script kiddies — can take the code and penetrate systems of users reading the advisory. The major problem here is that in any case, the advantage is on the Black Hat side. One of the issues is timing. If you are a Black Hat or a secu rity professional, you read these lists daily and you spend a lot of time with the information found there and in other sources. If you are responsible for your systems and also for system security, you do not spend all your time reading these lists. You probably never learned assembly or C and there fore perhaps cannot actually comprehend the exploit codes. This means that, even if both parties have the same information at the same time, the defender has the disadvantage of a longer time needed to understand the 49

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS issue. Then, the attacker just has to identify a vulnerable target and break into it without having to worry about system crashes, data lost, and similar problems. On the other hand, the system owner has to make sure that pro duction is not affected. He probably has to schedule downtime, talk to his manager, and make sure he is allowed to apply the latest patch. He must also talk to the vendor of the software running on these servers and make sure the patch does not affect the functionality of application XYZ. If this is not enough, look at some program code sent to the full disclo sure mailing lists. The code is sometimes developed six months before it is actually posted to the list. Now, did the code hang around on the hard drive of this hacker for this time or did he give it to others? Did one of his peers give this code to yet another group of people? Was the code used to attack systems? Some speculate that a certain amount of exploit code is released only after the original developer(s) feel it does not bring any more advan tage to them. This would mean that a lot of intrusions actually use code that is not published and therefore not known in the wild. As you can see from the examples listed above, the spectrum of different opinions has increased over time. Most hacker groups no longer follow one ethic but either develop their own or just do not care. The fact that the skills required to develop new attack methods or good exploits rise over time makes hacker ethics even less important. People who spend their time developing such skills get an omnipotent feeling and rate other people only by their skills. Who needs ethics when he is the master of the game anyway? Opponents Inside The reader has probably heard but never believed this message: 80 percent of successful attacks come from the inside. But this does not limit the possible opponents inside your company to the number of people who would actually attack the systems you try to protect. A company is a collec tion of several groups with different interests. One of these interests is secu rity — but it is only one. You have managers and back office staff who want easy-to-use computer systems. You might have application developers who would like to have open systems for easy development. There might be finance people who actually care about security but will not tell you the status of it because you are not supposed to know anything about the stuff finance does. There are actually more threats to consistent security inside a company than outside. The Hostile Insider Would you give an average hacker a list of important hosts of your network including the Domain Name System (DNS) addresses, Primary Domain Controller, internal and external Web servers, application servers, and routers? Would you give him accounts on all these systems and tell him 50

Know Your Opponent how they work? Would you provide this attacker with enough time to dis cover the ins and outs of your network and server architecture and would you place his system behind the firewall so he can access all targets easily? That is what a hostile insider has to start with. The normal desktop system configuration contains more valuable data than any attacker from the outside could probably find out in several weeks. It provides the insider with all key information about your network and therefore lays out the targets in front of him in a very clear way. C:\>ipconfig/all Windows IP Configuration Host Name . . . . . . . . . . . : internal-host Primary Dns Suffix. . . . . . . : localdomain.com Node Type . . . . . . . . . . . : Broadcast IP Routing Enabled. . . . . . . : No WINS Proxy Enabled. . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix. : Description . . . . . . . . . . : 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) Physical Address. . . . . . . . : 00-08-74-9C-21-13 Dhcp Enabled. . . . . . . . . . : Yes Dhcp Server . . . . . . . . . . : 192.168.1.230 IP Address. . . . . . . . . . . : 192.168.1.5 Subnet Mask . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . : 192.168.1.250 192.168.1.251 The information available to the insider by just looking at this Internet Protocol (IP) configuration is awesome. It contains the default gateway, which is probably a router, the DHCP server address, the DNS servers, and the type of NetBIOS communication. This information alone provides some very interesting targets. Most companies try to limit administrative overhead by using a single point of authentication. This trend continues because directory services 51

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS are becoming more popular. But it means that the insider, having an active user account, can log into a range of systems with this account. Local priv ilege escalation is a lot simpler than attacking a system on which the attacker has no account. But maybe he does not actually need to do this. It very much depends on the goals of the attacker. If he is after confidential data, poor file permissions might be all that are needed. The insider has a lot of time at hand. Consider a person who works at this company for several years. During this time, the person probably sees a range of systems. If we draw some assumptions about hostile insiders, the picture becomes even scarier: • Insiders are aware of computer security issues to a certain degree. • When insiders utilize network resources, they have an eye on the security level of these and remember the softest targets. • When they discover the passwords of other users, they keep track of them. This might happen by looking over someone’s shoulder or simply because the person called and asked for a favor. • Insiders perform their information-gathering carefully and never per form any suspect activity on the company network (prior to choos ing the target and moment). These assumptions match a large number of employees of an average company. Insiders do not have to work in the information technology (IT) department — but they often do. An insider who decides to go for active attacks might go unnoticed for a long time. Even if someone notices failed logins, increased security warnings in the log files about refused file access, or refused connections, the normal assumption is that a flawed configuration is the source of the problem. When the same activities are observed at the perimeter of the network, the system administrator will probably take a closer look. Most, if not all, networks I have seen have several levels of protection on the outside but are simple computer networks on the inside. This applies to small office networks as well as worldwide corporate networks. Consider the scenario in Exhibit 1. This company has several hundreds of computers in a network, some servers, an outside firewall, and a demili tarized zone. Malory is our hostile insider. He wants to do some harm to the company without getting caught. Alice, working as firewall administrator, is con nected to the same company network. Because Alice does not want to walk over to the other building where the firewalls are located, she has permit ted her PC to access the firewall. The attack is pretty straightforward: Malory attacks — and successfully breaks into — Alice’s PC and installs a customized Trojan horse application 52

Know Your Opponent LAN DMZ Internet Firewall 1 Web Mail Firewall 2 Internal Network Malory Alice Exhibit 1. Company Configuration that supports keyboard logging. Now, he calls Alice and reports issues with the firewall. Alice connects to the firewall and enters her username and password into the appropriate dialog. Malory watches the process. Of course Alice does not find anything, but this is not unusual. Malory con tinues to log every key Alice presses for some days and thereby collects her Windows username and password as well as some other interesting information. When Alice goes to lunch and locks her screen, Malory uses the remote takeover functionality of his Trojan application to unlock the screen, logs into both firewalls, and changes the first rule to allow any inbound and outbound traffic. Then, he uses the Trojan application to remove all traces of it on Alice’s PC. Now, Malory connects to the next best IRC server, joins some cracker’s channel, and tells everyone that a com pany just messed with its firewall and he happened to notice that. He gives out the IP address range and disconnects. Now, the only place where traces of his activity could be found are Alice’s and Malory’s PCs. But who would suspect Malory in the first place? The result would be noticed first by customers connecting to the Web server and seeing a defaced Web page. After a range of attackers from the outside established a foothold in the company’s network, the responsible staff would be busy for some time trying to block further incidents. If the intrusions are not obvious and Malory contacted some skilled Black Hats, this can go unnoticed for several days. The “moral” is this: Hostile insiders are as (if not more than) dangerous as the people outside of your firewall. Corporate Politics It may seem strange to list corporate politics as an “enemy” of good secu rity and an abettor of hacking activity, but in a good portion of corpora tions this is an accurate statement. One could ask, for example, why the 53

THE STRATEGY BEHIND BREAKING INTO AND DEFENDING NETWORKS chief executive officer (CEO) of a corporation might be listed as an oppo nent of the security administrator. He is a placeholder for a more complex management situation. The general issue — and most readers will know this from their own experience — is that the security administrator or the security officer is responsible for companywide security but does not have the right to tell others how to plan, design, implement, and operate their systems. This is a common dilemma and no golden way around it exists. The interests of several groups are affected when security measures are taken. The art of security management is to make sure the other parties feel comfortable with the actions taken or required. If they can at least accept them, the opponent CEO is no longer an issue. A problem arises when internal company politics are used to force a certain software solution or concept into production despite the security manager warning about it. Security people fight external attackers every day, but tend to retreat when it comes to conflicts with their own manage ment. It is not a nice situation to fight battles in your own working environ ment, but the most successful security managers and administrators do it. Their goal is to have a secure network, keep it up and running, and mitigate the effects of new viruses or internal attacks. If this means they get angry looks at the coffee corner, they accept it. This should not be misunder stood. Readers are not encouraged to argue with each and every manage ment peer about new implementations and existing procedures until everyone hates them. It is rather a warning that the reader may sometimes be required to resist the desire to just agree with a dangerous solution because it makes his or her life easier. It does not. In the long term — and experience at many companies proves this — the dedicated security man ager or administrator will have a better reputation, even beyond the boundaries of the company. Conclusion This chapter has attempted to draw together some “threads” in terminology commonly used to describe the hacking community and its motivations and objectives. Hopefully, it has also demonstrated that hacking motivations are complex and difficult to quantify; some of the “profiles” and terminology typically used to describe hackers and their motivations are misleading in the sense that there are sometimes extremely “thin” lines that divide the White Hat, Gray Hat, and Black Hat communities. This does not make the terminology useless, as long as the broader spectrum and complexity of the hacking community are well understood. The chapter also presented some differing perspectives on the subject of “ethics” and some of the controversy surrounding the “full disclosure” movement. As with any discussion on the subject of “ethics” (and though there are some reasonable ground rules for the security community) — the 54

Know Your Opponent subject appears much more complex when viewed from the perspective of the attacker. The final chapter section made some fundamental points about some of the “enemies” of sound organizational security — some of whom operate within the confines of your own organization. The fundamental idea is to draw your own conclusions. The intent was to stir up some debate on this subject, because ultimately any attempt to strictly map out the hacking community or its motivations will fall short when it comes to the examination of a specific incident or the motivations of a particular individual. This is ultimately what presents the challenge in analyzing the moves and countermoves of your opponent, and in improv ing your own “chess game.” Notes 1. Dan Farmer, Wietse Venema, 1993. “Improving the Security of Your Site by Breaking Into It,” (http://www.fish.com). 2. Reference, “Hacker versus Cracker,” Bob Woods (CNN/Newsbyte). 3. Reference, The New Hacker’s Dictionary, 3rd Ed., Eric S. Raymond, MIT Press. 4. The context for this comment was the U.S. spy plane incident of 2001. 5. See http://bofh.ntk.net. 6. For all readers who do not know how to read this, it says: “Your security sucks, generic hacker.” 7. Reference http://www.securityfocus.com for additional information on full disclosure. 55