Contents in Detail
ATTACKING NETWORK PROTOCOLS
A Hackers Guide to Capture, Analysis, and Exploitation
by James Forshaw
San Francisco
ATTACKING NETWORK PROTOCOLS. Copyright 2018 by James Forshaw.
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.
ISBN-10: 1-59327-750-4
ISBN-13: 978-1-59327-750-5
Publisher: William Pollock
Production Editor: Laurel Chun
Cover Illustration: Garry Booth
Interior Design: Octopod Studios
Developmental Editors: Liz Chadwick and William Pollock
Technical Reviewers: Cliff Janzen
Additional Technical Reviewers: Arrigo Triulzi and Peter Gutmann
Copyeditor: Anne Marie Walker
Compositors: Laurel Chun and Meg Sneeringer
Proofreader: Paula L. Fleming
Indexer: BIM Creatives, LLC
For information on distribution, translations, or bulk sales, please contact No Starch Press, Inc. directly:
No Starch Press, Inc.
245 8th Street, San Francisco, CA 94103
phone: 1.415.863.9900;
www.nostarch.com
Library of Congress Control Number: 2017954429
No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.
The information in this book is distributed on an As Is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.
About the Author
James Forshaw is a renowned computer security researcher at Google Project Zero, with more than ten years of experience in analyzing and exploiting application network protocols. His skills range from cracking game consoles to exposing complex design issues in operating systems, especially Microsoft Windows, which earned him the top bug bounty of $100,000 and placed him as the #1 researcher on Microsoft Security Response Centers (MSRC) published list. Hes the creator of the network protocol analysis tool, Canape, which was developed from his years of experience. Hes been invited to present his novel security research at global security conferences such as BlackHat, CanSecWest and Chaos Computer Congress.
About the Technical Reviewer
Since the early days of Commodore PET and VIC-20, technology has been a constant companion (and sometimes an obsession!) to Cliff Janzen. Cliff discovered his career passion when he moved to information security in 2008 after a decade of IT operations. Since then, Cliff has had the great fortune to work with and learn from some of the best people in the industry, including Mr. Forshaw and the fine people at No Starch during the production of this book. He is happily employed as a security consultant, doing everything from policy review to penetration tests. He feels lucky to have a career that is also his favorite hobby and a wife who supports him.
BRIEF CONTENTS
CONTENTS IN DETAIL
THE BASICS OF NETWORKING
CAPTURING APPLICATION TRAFFIC
NETWORK PROTOCOL STRUCTURES
ADVANCED APPLICATION TRAFFIC CAPTURE
ANALYSIS FROM THE WIRE
APPLICATION REVERSE ENGINEERING
NETWORK PROTOCOL SECURITY
IMPLEMENTING THE NETWORK PROTOCOL
THE ROOT CAUSES OF VULNERABILITIES
FINDING AND EXPLOITING SECURITY VULNERABILITIES
FOREWORD
When I first met James Forshaw, I worked in what Popular Science described in 2007 as one of the top ten worst jobs in science: a Microsoft Security Grunt. This was the broad-swath label the magazine used for anyone working in the Microsoft Security Response Center (MSRC). What positioned our jobs as worse than whale-feces researcher but somehow better than elephant vasectomist on this list (so famous among those of us who suffered in Redmond, WA, that we made t-shirts) was the relentless drumbeat of incoming security bug reports in Microsoft products.
It was here in MSRC that James, with his keen and creative eye toward the uncommon and overlooked, first caught my attention as a security strategist. James was the author of some of the most interesting security bug reports. This was no small feat, considering the MSRC was receiving upwards of 200,000 security bug reports per year from security researchers. James was finding not only simple bugshe had taken a look at the .NET framework and found architecture-level issues. While these architecture-level bugs were harder to address in a simple patch, they were much more valuable to Microsoft and its customers.
Fast-forward to the creation of Microsofts first bug bounty programs, which I started at the company in June of 2013. We had three programs in that initial batch of bug bountiesprograms that promised to pay security researchers like James cash in exchange for reporting the most serious bugs to Microsoft. I knew that for these programs to prove their efficacy, we needed high-quality security bugs to be turned in.
If we built it, there was no guarantee that the bug finders would come. We knew we were competing for some of the most highly skilled bug hunting eyes in the world. Numerous other cash rewards were available, and not all of the bug markets were for defense. Nation-states and criminals had a well-established offense market for bugs and exploits, and Microsoft was relying on the finders who were already coming forward at the rate of 200,000 bug reports per year for free. The bounties were to focus the attention of those friendly, altruistic bug hunters on the problems Microsoft needed the most help with eradicating.
So of course, I called on James and a handful of others, because I was counting on them to deliver the buggy goods. For these first Microsoft bug bounties, we security grunts in the MSRC really wanted vulnerabilities for Internet Explorer (IE) 11 beta, and we wanted something no software vendor had ever tried to set a bug bounty on before: we wanted to know about new exploitation techniques. That latter bounty was known as the Mitigation Bypass Bounty, and worth $100,000 at the time.
I remember sitting with James over a beer in London, trying to get him excited about looking for IE bugs, when he explained that hed never looked at browser security much before and cautioned me not to expect much from him.
James nevertheless turned in four unique sandbox escapes for IE 11 beta.
Four.
These sandbox escapes were in areas of the IE code that our internal teams and private external penetration testers had all missed. Sandbox escapes are essential to helping other bugs be more reliably exploitable. James earned bounties for all four bugs, paid for by the IE team itself, plus an extra $5,000 bonus out of my bounty budget. Looking back, I probably should have given him an extra $50,000. Because wow. Not bad for a bug hunter who had never looked at web browser security before.