Ted Harrington - Hackable: How to Do Application Security Right

Hackable

How to Do Application Security Right

Ted Harrington

copyright 2020 ted harrington

All rights reserved.

hackable

How to Do Application Security Right

isbn 978-1-5445-1767-4 Hardcover

isbn 978-1-5445-1766-7 Paperback

isbn 978-1-5445-1765-0 Ebook

To Mom and Dad, for inspiring me to serve others.

This book is a result of that ethos.

Why you need security and how this book will help you do it right.

Why you should constantly seek improvement. How to think like a hacker. How to multiply impact by combining in-house personnel with external experts.

How to choose between white-box and black-box. Why to share information rather than limit it.

How to tell the difference between penetration testing, vulnerability scanning, vulnerability assessments, and bug bounty programs (and pick whats best for you).

How to break your system, including what it means to abuse functionality, chain exploits, and seek the unknown unknowns.

How to fix your vulnerabilities in three phases: prioritize, remediate, and verify.

How to keep your application secure over time (and how to ensure reassessments are less expensive and more effective, too).

How to determine how much money (and effort) to spend on security.

How to determine what to protect, whom to defend against, and where youll be attacked.

How to do security sooner, better, and more cost-effectively without slowing down development.

How to gain a competitive advantage and turn it all into sales.

How to take action.

To those who seek excellence: this book is for you.

You are not alone.

Introduction

Lie

Security is a headache.

truth

Security is a competitive advantage.

Youre at the beach. You pick up a grain of sand and then toss it back. Later, your friend goes to the same beach and picks up a grain of sand. What are the chances that its the same one you picked up?

Pretty unlikely, right?

Now multiply that by every beach on earth. And multiply that by a gazillion earths. Thats what cryptographers might call statistical improbability. It gives you a sense of how unlikely it is that anyonehuman or machinecould guess the private key that secures a cryptocurrency wallet. Keys simply cant be predicted.

Or can they?

Well, we did. A bunch of times, in fact.

We published security research on Ethereum wallets that discovered a flaw in how the software provisions private keys. The flaw enabled us to successfully predict 732 of them.

Thats like picking up your exact grain of sand 732 times! It shouldnt be possible once , let alone hundreds of times!

A crucial component of what keeps cryptocurrency wallets secure is the statistical improbability that anyone could guess the private key. Weak keys mean that walletsand all the currency in themare vulnerable. If exploited, an attacker could access the accounts, transfer funds, and do anything else the legitimate owner of the wallet could do. When theres a weak key protecting a cryptocurrency wallet, its like a pile of cash is sitting on a sidewalk. Someone is going to steal it eventually.

And someone did.

We discovered that literally every single unit of currency that was once kept in those 732 vulnerable wallets had been transferred out. All of it was funneled into a single destination wallet. We had clearly stumbled upon a hacking campaign in progress.

It gets even crazier. It wasnt a small amount of money that was stolen either. Quite a bit, actually: $54,343,407.

Fifty-four million dollars! The scope of the theft was substantial.

Next, we wanted to see how quickly vulnerable wallets are looted. To answer that, we put $1 of our own Ethereum into one of the vulnerable wallets to see what would happen. Almost instantly, the money was gone. Snap your finger, and thats how quickly our money was transferred to the same wallet where the rest of the stolen money had gone.

This thiefwhom we dubbed Blockchain Banditwas actively stealing from vulnerable wallets. The massive theft was achieved by exploiting the same vulnerability our research had discovered.

This story powerfully demonstrates two simple facts. First, software flaws exist. Second, attackers exploit them.

Stories like this are both unexpected and yet not uncommon. Applications are exploited every single day. Its why this book needs to exist.

Application security is the process of finding, fixing, and preventing security vulnerabilities in order to improve the security of an application. Security vulnerabilities are weaknesses that an attacker can exploit in order to perform unauthorized actions within a computer system.

The question is not whether vulnerabilities exist in your applicationthey do. Your vulnerabilities exist. No, the real question is simply which happens first: will attackers exploit them, or will you fix them?

It needs to be you.

Thats why youre holding this book in your hands. Its your responsibility to make sure that the software your company develops is secure. Until security is done right, you accept unnecessary risk, while security gets in the way of sales.

You need to reduce risk. You need to win sales.

Theres just one problem, though...

Security Is a Minefield

Sometimes companies approach security as if its a necessary evil, something they dont want to do but know they must. When that happens, security fails to be a priority, which turns it into a blind spot. Complicating this, theres a lot of misinformation out there (which is why each chapter in this book opens with a lie and then a truth you should replace it with).

Many companies dont know which security approaches work and which dont. Other companies dont even know where to start. They arent sure what to assess, what to prioritize, or how much to spend. They dont know how hackers think or break systems. They dont know the best way to find their vulnerabilities. They dont know the best way to fix them.

Worse, companies sometimes think they do know those things, only to later learn they were actually doing it wrong the entire time.

Here are some of the most common problems that companies faceor think they facewhen approaching security:

• Their developers juggle many priorities. Security is just one. Yet, usually, the top levels of leadership determine which priorities to emphasize. When leadership doesnt understand or prioritize security, their developers simply cant allocate sufficient time to it.
• Security isnt the primary focus of their training either. Developers are usually brilliant people trying to build clean, efficient, effective code. Theyre not always thinking about how to break it. By contrast, attackers spend every waking minute studying how to break that clean, efficient, effective code.
• Companies tend to believe that security slows down development. As a result, deadlines cause security to get postponed. This just causes regressions and rework later. It makes things harder and more expensive in the long run.