Quantcast

How to Disclose or Sell an Exploit without Getting in Trouble

James DenaroJames Denaro, patent attorney at CipherLaw, delivers a presentation at Defcon highlighting the legal risks InfoSec researchers might run into in their activity.

The topic for today is how to disclose or sell an exploit without getting in trouble. I’m Jim Denaro. I’m an intellectual property attorney based out of Washington, D.C. I focus my work exclusively on information security technologies.

The disclaimer

The disclaimer

So, here we go. Because I’m an attorney and this does have some legal component to it, although this is not a law talk, really, I have to give the standard disclaimer (see right-hand image) that this presentation is not legal advice about your specific situation or your specific questions. Even if you ask me a question – we are still talking about hypotheticals – if we develop an attorney-client relationship, then we’re talking about your specific problem and giving specific legal advice. So this presentation does not create attorney-client relationship alone; we can maybe do that later.

Issues to be covered

Issues to be covered

This (see left-hand image) is a quick overview of what we’ll try to accomplish here. We’re going to cover the types of risks that are being faced by researchers; risk mitigation strategies that researchers can take to try to reduce those risks; some of your options for disclosing a vulnerability that may have less risk; and then some of the risks that are associated with selling an exploit. The overall goal of this is to make yourself a harder target. If someone ever asks you: “Can I be sued if I do this or if this happens?” – the answer is always “Yes.” You can always be sued by anybody for anything at any time. The only question is who is going to win. And the goal is to make it more likely that you will win, which disincentivizes someone from actually suing you in the first place.

Some risk examples

Some risk examples

So, let’s start out with just some great examples of the kind of research activities that might get somebody in trouble (see right-hand image). These are generally real life cases. For example, you found out how to see other people’s utility bills by changing the http query string. I talked to someone at the party the other night who had done just exactly that; he was wondering what to do about it. Another example: you discover your neighbor’s WiFi is not protected. How did you find that out..? Yet another instance: you broke the crypto that’s protecting some media that you had. It’s getting a little more serious now, that’s actual money at stake. Maybe you wrote a better remote access tool – that sounds like you might make a lot of money.

Techniques might cause trouble

Techniques might cause trouble

Many of the same risks apply, surprisingly enough, whether you are just looking at changing http strings or you are actually taking apart a DVD. So, in general we’re talking about techniques; I’ve sort of defined it here (see left-hand image) broad spectrum: everything from a technique that might be used for denial-of-service attacks, to something that’s sort of investigatory web browsing.

Risks before disclosure

Risks before disclosure

Okay, first, when is there risk for a security researcher? There are three general areas where we see the risk starting to show up (see right-hand and bottom image). One – there can be a threat of legal action before you go to a conference or make this disclosure. There’re some examples listed here. You might be the recipient of a legal action seeking an injunction barring you from disclosing something before a conference.
Post-disclosure risks

Post-disclosure risks

So, now we move from merely saber-rattling to an actual lawsuit being filed against you. And then, there’s a possibility of a legal action being initiated against you after you make the disclosure. And these are all real examples.

The Computer Fraud and Abuse Act - researcher’s possible legal adversary

The Computer Fraud and Abuse Act – researcher’s possible legal adversary

Your #1 concern is typically going to be the Computer Fraud and Abuse Act (see right-hand image); you’ve probably heard a lot about that lately, perhaps here or at other conferences. The main issue is that it prohibits access “without authorization” or “exceeding authorized access”. The two times when you’re likely to run into possibly exceeding authorized access or acting without authorization would be in the investigatory phase of working on whatever technique it is that you’ve got, and when you actually create a tool that performs whatever this technique is. You might actually have a problem where that tool does the act that is prohibited.

Checking for a CFAA abuse problem

Checking for a CFAA abuse problem

Everyone’s talking much about how vague this notion of “authorization” is in the Computer Fraud and Abuse Act. I’ve created a handy checklist (see left-hand image) to figure out if you might have a Computer Fraud and Abuse Act problem. So, there you go. Are you connected to the Internet? Probably. Are you accessing a remote system? Probably. Do you have permission to access that system? This is the real hard question – it’s really hard to know if you have permission. If you saw a banner go by that said: “You don’t have access,” you probably don’t have access. But there are a lot of cases where it’s not so clear, and that’s really where you have sort of the Andrew Auernheimer situation, where he’s querying a public-facing API on a repeated basis; no one asked him to do that, but there’s no banner, there’s no clear prohibition of doing that – it was a public-facing API after all. Really, there’s some risk in figuring out whether or not you have permission, but that’s really all it takes.

It’s not about you only

It’s not about you only

Unfortunately, it’s not just about what you do. The Computer Fraud and Abuse Act is about what your friends do. And I believe the risk of being caught up in conspiracy to violate the Computer Fraud and Abuse Act is certainly enhanced by the prevalence of social media today. So, if you’re on Twitter or some other very easy-to-use social media platform, you’re talking to your friends about how you might do something or answering questions about how you might do a certain thing with a technique that you’ve developed – you’re starting to head down the road of conspiracy.

Conspiracy typically does require an overt act in order to really fulfill the conspiracy, and typically just discussing something with someone does not. But if you start providing technical support for something that someone else is doing, you’re definitely increasing the risk of being caught up in a conspiracy to violate the Computer Fraud and Abuse Act, if not actually violating yourself.
 

Read next: How to Disclose or Sell an Exploit without Getting in Trouble 2: CFAA and TRO Risk Mitigations

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: