How to Disclose or Sell an Exploit Without Getting in Trouble
Denaro, James
You have identified a vulnerability and may have developed an exploit. What should you do with it? You might consider going to the vendor, blogging about it, or selling it. There are risks in each of these options. This 20-minute session will cover the legal risks to security researchers involved in publishing or selling information that details the operation of hacks, exploits, vulnerabilities and other techniques. This session will provide practical advice on how to reduce the risk of being on the wrong end of civil and criminal legal action as a result of a publication or sale. James Denaro is the founder of CipherLaw, a Washington, D.C.-based consultancy and focuses his practice on the legal, technical, and ethical issues faced by innovators in information security. Jim is a frequent speaker and writer on the subject of intellectual property issues in information security and has experience in a wide range of technologies, including intrusion detection and prevention, botnet investigation, malware discovery and remediation, and cryptography. Jim has completed professional coursework at MIT and Stanford in computer security and cryptography. He also holds technical certifications from the Cloud Security Alliance (CCSK) and Cisco Systems (CCENT), and has passed the CISSP examination (pending certification). Before becoming an attorney, Jim spent obscene amounts of time looking at PPC assembly in MacsBug Jim is a registered patent attorney and is admitted to practice in the District of Columbia, California, Maryland, and Virginia. Jim has undergraduate degrees in computer engineering and philosophy and is currently pursuing graduate legal studies in national security at Georgetown. Jim was formerly with the international law firms of Morrison & Foerster and Perkins Coie before founding CipherLaw.
 So the topic for today is how to disclose or sell an exploit without getting in trouble. I'm Jim Dinaro. I'm an intellectual property attorney based out of Washington, D.C. I focus my work exclusively on information security technologies. Before I went to law school, I used to spend far too much time just tweaking around on MaxBug on my power PC and figured that no better way to keep doing that than to do this. So here we go. Just 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 that this presentation is not legal advice about your specific situation or your specific questions. Even if you ask me a question, we're 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 an attorney-client relationship alone. We can maybe do that later. So this is a quick overview of what we're trying to accomplish here in the next 20 minutes. I'm going to speak quickly to make sure we get it all in. We're going to cover the types of risks that are being faced by researchers, some risk mitigation strategies that researchers can take to try to reduce those risks, some of your options for disclosing a vulnerability that may be less ‑‑ 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, well, 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's 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. So let's start out with just some great examples of the kind of research activities that might get somebody in trouble. For example, some of these are generally real life cases. You found out how to see other people's utility bills by changing the HTTP query string. I talked to someone at a party the other night who had done just exactly that. He was wondering what to do about it. You discover your neighbor's Wi‑Fi is not protected. How did you find that out? You broke the crypto that's protecting some media that you had. It's getting a little more serious now. There's actual money at stake. And maybe you wrote a better remote access tool. That sounds like you might make a lot of money. So many of the same risks apply, surprisingly enough, whether you're just looking at changing HTTP strings or whether you're actually taking apart a DVD. So in general, we're talking about techniques. I've sort of defined it here. Broad spectrum, everything from denial of service, a technique that might be used for denial of service attacks to something that's just, you know, more akin to sort of investigatory web browsing. Okay. First, when is there risk to a security researcher? There are three general areas where we see the risk starting to show up. One, there can be a threat of legal action before you go to a conference or make this disclosure. There are some examples listed here. You might be the recipient of a legal action seeking an injunction barring you from disclosing something before a conference. So we now remove from merely saber rattling to an actual lawsuit being filed against you. And then there's the possibility of a legal action being initiated against you after you make the disclosure. And these are all real examples. You can, Declan McCulloch of CNET and his colleagues have written some very interesting articles that go into more detail about some of these cases. I would recommend them to you most definitely. But you might notice that some of these seem to be around black cat and deaf con on a pretty regular basis. So that's when it can happen. Your number one concern is typically going to be the computer front and view sacked. You probably heard a lot about that lately, perhaps here 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 your, 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. So in light of, you know, everyone's talked much about how vague this notion of computer fraud and abuse act is of authorization. I've created a handy checklist to figure out if you might have a computer fraud and abuse act problem. So there we 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 a 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 this sort of like the Andrew Orinheimer situation where he's querying a public-facing API on a repeated basis. No one asked him to do that. But there was no banner. There was no clear prohibition of doing that. It was a public-facing API, after all. So there's really some real risk in figuring out if you can ‑‑ whether or not you have permission. But that's really all it takes. 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 most certainly enhanced by the prevalence of social media today. So if you're on Twitter or some other easy, 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 is not. But if you start providing technical support for something that someone else is doing, you're really definitely increasing the risk of being caught up in a conspiracy to violate the computer fraud and abuse act if not actually violating yourself. So we've got some examples here where computer fraud and abuse act has been applied. I think it's helpful to look at some examples because that's how we see how it's being applied. And we can compare what we're doing to some of the things that have happened in the past, other people, and see how close those comparisons are. And since we're in Las Vegas, we absolutely have to talk about the case of Nestor. Nestor was really into video poker. And he liked to play and play and play and play. And he got really good at it. And he played it so much that he discovered a bug in the video poker software that enabled him to play one type of game and bid up a bunch of money into that game and then switch to a different game and a multiplier would be applied to his bid. So when he won, he got this enormous payout. And he figured out how to reproduce this bug very efficiently. So he was doing it and his friends were doing it and they were getting a lot of money. And obviously eventually, how these stories always end, he gets caught. And he was charged with, amongst other frauds, violating the computer fraud and abuse act. And as we were just looking at the computer fraud and abuse act a few moments ago, we saw it's really mostly about unauthorized access or exceeding an authorization that you had. And it's hard to imagine how sitting ‑‑ he didn't access the firmware, he didn't take the game apart, he just sat there putting money in and pushing the buttons on the surface of the machine. How you could exceed authorized access to a video poker machine is absolutely mind boggling. But nonetheless, those charges were levied against him. Ultimately, the Department of Justice did not pursue those charges. Those charges were dropped. They went ahead with other fraud charges. But nonetheless, for some period of time, he was facing computer fraud and abuse act charges for doing exactly that. It's also worth looking at the tragic case of Aaron Swartz who spoofed his MAC address to download journal articles. That was a computer fraud and abuse act crime. Andrew Orenheimer who allegedly conspired to run an automated script to plug in identifiers for iPads and get email addresses. Didn't even do it himself. He's doing several years in federal prison for that. Also worth noting that the Department of Justice has said in their manual about the computer fraud and abuse act that conspiracy to hack a honeypot can violate the computer fraud and abuse act. There's really no end to the sorts of things that could possibly violate the computer fraud and abuse act. So you're looking at a situation where the computer fraud and abuse act almost acts as an ex post facto law where the Department of Justice is able to look at what you did after the fact. And if they don't like it or they don't like you for whatever reason, you may be trollish for some reason. You are likely to be on the wrong end of a computer fraud and abuse act prosecution. There's also a civil cause of action provided by the computer fraud and abuse act. So the company that ‑‑ wherever the target is of this exploit can also pursue whoever accessed the system without authorization. So the question then is what can we ‑‑ is there anything we can do to try to reduce our chances of being on the wrong end of this type of lawsuit? Well, let's take a quick ‑‑ we don't want to go too far in a statute. It's not a continuing legal education conference. But let's take a quick look at the statute and see if there's some key words we can at least identify. Here we have whoever having knowingly accessed a computer without authorization. Another part of the statute, whoever intentionally accesses a computer without authorization. So one of the things you can do is to try to avoid unintentionally creating knowledge and intent. It's a little bit hard to do this for yourself if you intend to do something. But at least you can avoid doing it in connection with other people. So for example, I would suggest that you do not direct information about how to use some kind of technique to someone that you suspect or have reason to know is likely to use it illegally. Be careful in providing technical support for some clever new technique that you've developed. So my advice, if I were your lawyer, I would advise you not to answer that tweet. If someone is tweeting to you, I would advise you to ask you about how to make something more effective, perhaps. This slide is a little more detailed. Some more approaches that you might take. Don't provide information possibly directly to individuals, especially if you're not sure who they are or what they might be up to. Consider just posting things on a website only. Do not post information to forums where you suspect or forums that are known to generally promote illegal activity. If you publish it on your own website or you have control of the post, consider disabling comments so you don't have a situation of people discussing potentially illegal uses of your technique. And lastly, don't maintain logs. So one of the things we've seen happen, that's enough for the computer fraud and abuse act for now. There's not a whole lot you can really do about it beyond just being careful. Let's move on to the temporary restraining order. This is particularly timely, actually, because you may have read the story about the BW group and the megamos encryption that was used on the vehicle immobilizers. So some European security researchers had figured out how to bypass the ‑‑ or discover a flaw in the encryption that was used on the vehicle immobilizers that were used in BW group cars like Porsche and Audi and Bentley. And they're going to present this at the USNIX conference in Washington, D.C. in a few weeks. And they got themselves slapped with a temporary restraining order preventing them from making this disclosure at the conference. How did this happen? And how can we prevent this from happening again? We've seen this here at DEF CON and Black Hat. The talks have been stopped by a temporary restraining order. So take a quick look at the factors that the courts look at when deciding whether or not to grant a temporary restraining order to prevent a researcher from disclosing some information about a vulnerability. Number one, will the requester, so in that case it would be the BW group, suffer irreparable harm if the TRO does not issue. Good evening, sir. Who knows how this works? Is he a new speaker? It's really hard to get accepted to speak at DEF CON. You should all be thinking about how you're going to create speech talks. I've been drinking all day. Talks to eventually have yourselves up here, right? A big round of applause for Jim. All right. One more order of business. We need a new person who's first time at DEF CON. First hand up right there. Red shirt. Come on up on the stage. We've got a little extra. Let's get one more. We're going to get two people. All right. First hand up over there. There we go. All right. Cheers to our new speaker. All right. Let's see if he can pick up where he left off. We're going to work on new material for tomorrow. Thank you. Thanks, guys. All right. So that was great. Thank you. So just a quick look at some of the factors that the court's going to look at when deciding whether or not to grant the temporary training order. Will the requestor suffer irreparable harm if the TRO does not issue? Pretty easy to imagine. You've got an embedded system and someone's figured out how to break it. It's going to be almost impossible for them to update it in any reasonable amount of time. Usually expensive. Probably some irreparable harm. That basically means that money isn't going to fix it very easily. So that goes in VW Group's favor. Will there be an even greater harm to the researcher if the TRO does not issue? What your paper got delayed? You couldn't put in some part of the algorithm. Maybe you had to pare it back. Hard to see that as a huge harm to the researcher. We might feel really bad about that. But in terms of the use of money, VW Group is going to have to pay to fix this. It's not really going to look too good for the researcher there. The public interest is just kind of a fun one. Because we might think that, well, the public interest clearly favors disclosing the vulnerability so it can be fixed. This court's probably going to go the other way on that and see that really the risk to all these BMWs or other Porsches and Bentley's and things being stolen is much greater, is much more in the public interest than having your really obscure crypto talk go forward. The last factor is the likelihood they request a role to mainly prevail. And this is really the one we need to focus on. Because the VW Group has to have a cause of action. They can't just say we don't like it. They have to say here's why you need to stop. And it's because you did something bad to us. And in the case of the VW Group, the Megamos case, and also in the case of the Cisco disclosure, what we had was the use of copyrighted material. And that's really what ‑‑ that was the hook that got the TRO to issue. So the obvious advice then is to avoid the use of copyrighted material. So if you include source code or object code from whatever it is that you're working on, that gives leverage to whoever it is that wants to stop you from disclosing it. There is a fair use exception if you use little bits and pieces of code. That's a case by case analysis. And you can't just say, well, this is going to be fair use. It depends on how much you use and other factors that are very specific to what's actually going on in your case. So just try to avoid it if you can. It may not be possible. But to the extent you can do that. Also avoid darknet sources for wherever you're getting this stuff. In the Megamos case, the court actually talked about the fact that the researchers obtained some information about how the Megamos system worked through some sketchy channels. I don't recall it saying exactly where they got it, but it was some sort of bit torrent, P2P type thing, wherever they got it. It wasn't from a group or Megamos. So another thing you want to do is be aware of preexisting contractual relationships that you as a security researcher might have with the target of whatever it is you're working on. These contractual agreements could come in the form of a term of service and use your license agreements, non‑disclosure agreements or employment agreements. What's that? An in‑user license agreement might very well have provisions in it that prohibit reverse engineering software, for example. That's something you might be doing as part of your exploration into your technique. That could give leverage to someone to try to stop using oh, you've breached this. Nothing's for certain. It's just an argument that they have. It's something ‑‑ there's not much you can do about it. Pretty much every piece of software you get is going to have some kind of license agreement that's going to ‑‑ assuming you came to it legitimately, right? You've agreed to this license that may prohibit you from doing certain things with that software. There's not a whole lot you can do about that. But you at least can be aware of the risk, if nothing else. So how far you need to go in trying to mitigate the risk? Somewhat depends on the techniques that you've used in your research. If you've done things that are clearly ‑‑ that clearly look like some of the examples of what people have done that's gotten them prison time, that's something you need to be careful of and maybe take more aggressive mitigation techniques in order to perhaps hide some of the information about what you're doing. So for example, if in the mega‑most case, no one had identified that it was the VW group that was ‑‑ where this crypto system had been compromised, VW group would not have been able to issue ‑‑ to go after a temporary restraining order against the researchers. So perhaps there's an opportunity here for the conference‑going community to create a track where people could present things that are sort of get like a little asterisk or something next to it and we all recognize that this is something that had to be kept quiet. It's sort of like a confidential disclosure, trust the review board, this is going to be really cool, but we just can't really tell you about what it is because then you won't get to hear it. So maybe that's one approach. So I'd like to talk about some of the ways that you might make a disclosure that are relatively less likely to get you in trouble. You can obviously disclose to the responsible party. That's what we'd like to do, that's sort of what the responsible disclosure paradigm is all about. You found a problem with the system, you tell who's running the system. This is actually unfortunately relatively high risk and that risk scales with the questionableness of whatever technique it was that you used to find out about this vulnerability. So if you're connected to the Internet, you access the remote system and you have net permission, that's how you did it. It may not be a great idea to go tell them about it because if they don't like it, they've got an action against you. If you're inconvenient, that's a problem for you. You might think you're doing them a favor. They might not agree that you're doing them a favor. If you're able to submit it anonymously to whoever the vendor is or the responsible party, that's great. Depends how good your Opsac is, I suppose. A lot of times you think you're maybe anonymous, but you're not as anonymous as you thought you were or hoped you were. So that's a risk in itself that you need to consider. If you submit to a bug bounty, presumably they've invited it, maybe you're at less risk. You can disclose to a government authority, perhaps. Maybe you don't really believe it, I'll ever get to the vendor. But again, if your techniques were perhaps questionable, you might not necessarily want to be submitting it to a government, a government authority. You may want to separately, you may have an interest in keeping your own identity anonymous. Again, you can try to submit anonymously to the government, but I don't know how much we can really trust that anymore. Fortunately ‑‑ this is a legal talk and somewhat legal talking. You can almost never get to a legal talk where someone will actually tell you something for sure. Like, absolutely, 100%, you will not get in trouble if you do this. But fortunately, we are in a case here where there is one group of people who really don't have to worry about getting in trouble with a computer front of use act when they disclose the vulnerability and here they are. You know, okay to disclose if you're one of these people. Although she really should not have been hacking the palace computer, we're not going to hold that against her. So we're thinking about ways that we might be able to leverage opportunities for security researchers to make disclosures while keeping the risk as low as possible. So we're working on creating a pilot program where attorney client privilege can be leveraged to hide the identity and techniques used by security researcher in making a disclosure. So the concept works like this. The researcher would disclose the vulnerability to a trusted third party, which would be an attorney, only to the attorney. It's critical that this be a completely confidential disclosure to maintain the confidentiality of that disclosure so that other entities on the outside can't get to it. The trusted third party does not publish the vulnerability on behalf of the researcher. However, the trusted third party does disclose the vulnerability to whoever the affected party is, whoever has this vulnerability. The researcher remains anonymous during the entire process. This is possibly abuse if there's no better option. It's a little bit cumbersome and there are some side effects chiefly that the researcher remains anonymous, doesn't get public credit for whatever the research was, but it is one possible way for the researcher to be able to disclose and remain about as anonymous as one can possibly get. So this is a pilot program. We're currently working on it. We're kicking out the bugs right now. So if anyone's interested in talking to us further about this, we definitely welcome your input and please see me afterwards. We should now turn to selling very quickly. Right now, there is no law in the U.S. that prohibits the selling of an exploit. And that is a situation that is probably likely to change in the not too distant future, but for now, there's really not too much to worry about unless the techniques of course going back, if you're developing your exploit have some problem, then you still have a problem. But the fact of the sale itself is not something that's going to get you in trouble. However, there's a lot of focus on this market now. And here are some recent articles from May of 2013, booming zero day trade as Washington experts worried. And my favorite, the U.S. Senate wants to control malware like it's a missile. Stuff is dangerous. So every year, the Congress has passed the National Defense Authorization Act. It sets the budget for DOD and includes a bunch of other stuff that gets stuck in there. And this year, well, for 2014, the Senate version, it hasn't been passed yet, it's still in Congress. The Senate version has provisions that seek to begin the process of regulating the sale of exploits. The bill, the House version doesn't have this. This is still just in the Senate. But I think this is where it's headed. The bill notes that the President shall establish a process for developing policy to control the proliferation of cyber weapons through a whole series of possible actions, right? Export controls, law enforcement, financial, diplomatic engagement, and so on. The Senate Armed Services Committee that had the bill before it was passed to the rest of the Senate said they had some commentary on this. And they referred to the dangerous software, a global black market, a gray market. It starts to look really bad. But they note that there is ‑‑ we need to have a carve out for dual use software and pen testing tools. In Europe, the European Parliament recently passed a directive. They're a little bit ahead of us. This prohibition on the sale of tools, as they call it, exploits, will be required to be enacted by all of the member states in short order. And this provision prohibits the production, sale, procurement for use, import, distribution of these tools that could be used to commit these enumerated defenses, which is pretty much all the bad things that you can think of doing with a computer. However, there's an exception. It's a very important exception. For tools that are created for legitimate purposes, that's just to test the reliability of systems, and it further notes that there needs to be ‑‑ in order to violate this law, you need to show a direct intent that the tools be used to commit some of the offenses. So in both cases, both in the U.S. and in Europe, we're seeing this trend, well, it's really going back to the definitional problem. How do we define what an exploit is, and how do we make sure that legitimate tools are ‑‑ can still be bought and sold? So this is kind of perspective. We don't know what the laws are actually going to look like, but I would start thinking like this. Think about dual‑use tools. If you write something, don't put it together as the next greatest hack. You're creating pen testing tools. This has gone on for a long time. If you look at software, I'm sure you all used it. Copy 2 plus, anybody? Backup software. And the manuals for these software have these elaborate disclaimers. This is strictly being used to back up your floppy. This is not being used to make illegal copies. And that is really the conundrum. And I think that's where ‑‑ that's where exploits will go. And some exploits will never be able to be looked at as a dual‑use tool for sure. If you have a nuclear missile equivalent of an exploit, it's hard to justify the pen testing value of that. But for a lot of tools, there is a will fall into this area. That's where perhaps they should go. Some other things you might do if you are selling, know your buyer to the extent you can. I think regulation is just one bad outcome away. What's going to happen is someone in the U.S. is going to sell an exploit, go through some channel, and come back and get used against some U.S. interests. We may not hear about it. It may be a matter of, you know, maybe a secret. But this will happen. And then there will be a huge drive to stop this from happening very quickly. It's the same reason, you know, as soon as someone is murdered with a certain type of weapon, that weapon has to be banned, that's going to happen here. The laws are created in this country is very reactionary. And I expect that trend to continue here. So maybe you can prevent that from happening. So know your buyer. If you're selling something, don't sell it to a channel where it's likely to go to some country that's under an embargo with the United States. Maybe your best bet is just to sell it to the U.S. As for assurances from your buyer, so you don't have knowledge that is going to someplace where it's not supposed to go. You could be lied to, but you can't control everything, right? But at least you can get an assurance that it's not going to be used in some illegitimate way. And also, you could always use disclaimer language. So I have some nice examples of disclaimer language here. This huge chunk of text on the top is actually from a software product that many of you have probably used many times. It's good stuff. I've highlighted probably the best of the operative language in it. But if you're selling something, be sure to use some disclaimer language about that kind of flows along these lines. That would help you from being charged and being complicit in any sort of illegal use to which the software might eventually be put. And lastly, I'd just like to highlight this bottom little paragraph, which is actually from the Apple iTunes store. It's the end user license agreement that comes with that. And it requires that you agree that you will not use these products for any purpose prohibited by the United States law, including without limitation, to development design, manufacture, production of nuclear missiles or chemical or biological weapons. Thank God. Words with friends. That is dangerous stuff. So thank you for coming. This is my contact block. So I think we have some time here for questions. So if people want to line up, I'm happy to entertain them as best we can. There are definitely free speech issues, especially in the temporary restraining order context. Oh, second amendment, sorry. Second amendment challenge? Come see me after about that. Question back here. Question. Let's connect on that. Let's connect on that. Okay. So what about using a corporation to limit your liability for disclosure or selling? Is that been utilized? Corporations can be held liable in many cases. In fact, even under the computer fraud and hasn't happened yet, but a corporation could be held liable. Done? Question regarding full disclosure versus responsible disclosure. So when we do it, we do it via responsible disclosure. We contact a vendor, we give them 30 days and we tell them our intent to publish and we publish everything. So the actual vulnerability and how to do it so that they can replicate and do whatever they want. In most cases, the vendors get a hot fix within a week and then if within 30 days they provide the hot fix, we spread them and say, you know, to fix it, install hot fix, whatever. Sometimes vendors will say we need more time, maybe we'll negotiate a couple of days, but sometimes they'll say we're not going to fix it and you can't publish it. So I won't explain what we do for that. But Google recently published the fact that they plan to disclose vulnerabilities within seven days, all right, to have a seven-day turnaround. So what happens if a company like Google, I don't know if these are worth threatening, but intends to publish a vulnerability within the seven-day turnaround period and that company says to Google, don't, if you do, we'll sue you. What happens in Google versus that vendor company? Well, Google is at risk if Google has some kind of obligation not to. I mean, if, it would depend on the specific circumstances of it, but in this case, I mean, if no law has been broken, then Google could be published without any caution. In the case for me, for example, where I contact a vendor and I say I've got the following ten vulnerabilities which I plan to publish and they come back to me and say, if you publish those, we'll sue you, right? And the same thing happens when Google say, well, we're not going to give you 30 days, we're going to give you seven days and the company comes back and says, Google, we're going to sue you if you publish. It doesn't carry the same weight where they're trying to sue Google as they're trying to sue me, for example. That helps as well, man. I mean, that's the unfortunate part. I mean, as a... But is it just a case of how good your legal team is, how expensive your legal team is? Exactly. How much do you charge? Where do you want to meet them at? Let's go. Where's good? Wherever you want to meet them at to carry on because it's about five or six other people. It's on the hall. So this talks over with. We've got to get it ready for the evening. Now on the hallway, we'll answer the rest of your questions. Unfortunately, there's not a Q&A because it's been disassembled too. Thank you all. Thank you.
 So the topic for today is how to disclose or sell an exploit without getting in trouble.  I'm Jim Dinaro. I'm an intellectual property attorney based out of Washington, D.C. I focus  my work exclusively on information security technologies. Before I went to law school,  I used to spend far too much time just tweaking around on MaxBug on my power PC and figured  that no better way to keep doing that than to do this. So here we go. Just 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 that this presentation is not legal advice about your  specific situation or your specific questions. Even if you ask me a question, we're 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 an attorney-client relationship alone. We can maybe do that later. So this  is a quick overview of what we're trying to accomplish here in the next 20 minutes. I'm  going to speak quickly to make sure we get it all in. We're going to cover the types of risks  that are being faced by researchers, some risk mitigation strategies that researchers can  take to try to reduce those risks, some of your options for disclosing a vulnerability that may  be less ‑‑ 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, well, 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's  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. So let's start out with just some great  examples of the kind of research activities that might get somebody in trouble. For example,  some of these are generally real life cases. You found out how to see other people's utility  bills by changing the HTTP query string. I talked to someone at a party the other night  who had done just exactly that. He was wondering what to do about it. You discover your neighbor's  Wi‑Fi is not protected. How did you find that out? You broke the crypto that's protecting  some media that you had. It's getting a little more serious now. There's actual money at  stake. And maybe you wrote a better remote access tool. That sounds like you might make  a lot of money. So many of the same risks apply, surprisingly enough, whether you're  just looking at changing HTTP strings or whether you're actually taking apart a DVD.  So in general, we're talking about techniques. I've sort of defined it here. Broad spectrum,  everything from denial of service, a technique that might be used for denial of service attacks  to something that's just, you know, more akin to sort of investigatory web browsing.  Okay. First, when is there risk to a security researcher? There are three general areas  where we see the risk starting to show up. One, there can be a threat of legal action  before you go to a conference or make this disclosure. There are some examples listed  here. You might be the recipient of a legal action seeking an injunction barring you from  disclosing something before a conference. So we now remove from merely saber rattling  to an actual lawsuit being filed against you. And then there's the possibility of a legal  action being initiated against you after you make the disclosure. And these are all real  examples. You can, Declan McCulloch of CNET and his colleagues have written some very  interesting articles that go into more detail about some of these cases. I would recommend  them to you most definitely. But you might notice that some of these seem to be around  black cat and deaf con on a pretty regular basis. So that's when it can happen. Your  number one concern is typically going to be the computer front and view sacked. You probably  heard a lot about that lately, perhaps here 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 your, 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. So in light of,  you know, everyone's talked much about how vague this notion of computer fraud and abuse  act is of authorization. I've created a handy checklist to figure out if you might have  a computer fraud and abuse act problem. So there we 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 a 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  this sort of like the Andrew Orinheimer situation where he's querying a public-facing API on  a repeated basis. No one asked him to do that. But there was no banner. There was no clear  prohibition of doing that. It was a public-facing API, after all. So there's really some real  risk in figuring out if you can ‑‑ whether or not you have permission. But that's really  all it takes. 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 most certainly enhanced by the prevalence  of social media today. So if you're on Twitter or some other easy, 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 is not. But if you start providing technical support for something that someone  else is doing, you're really definitely increasing the risk of being caught up in a conspiracy  to violate the computer fraud and abuse act if not actually violating yourself. So we've  got some examples here where computer fraud and abuse act has been applied. I think it's  helpful to look at some examples because that's how we see how it's being applied. And we can  compare what we're doing to some of the things that have happened in the past, other people,  and see how close those comparisons are. And since we're in Las Vegas, we absolutely have  to talk about the case of Nestor. Nestor was really into video poker. And he liked to play  and play and play and play. And he got really good at it. And he played it so much that he  discovered a bug in the video poker software that enabled him to play one type of game and  bid up a bunch of money into that game and then switch to a different game and a multiplier  would be applied to his bid. So when he won, he got this enormous payout. And he figured  out how to reproduce this bug very efficiently. So he was doing it and his friends were doing  it and they were getting a lot of money. And obviously eventually, how these stories always  end, he gets caught. And he was charged with, amongst other frauds, violating the computer  fraud and abuse act. And as we were just looking at the computer fraud and abuse act a few  moments ago, we saw it's really mostly about unauthorized access or exceeding an authorization  that you had. And it's hard to imagine how sitting ‑‑ he didn't access the firmware,  he didn't take the game apart, he just sat there putting money in and pushing the buttons  on the surface of the machine. How you could exceed authorized access to a video poker  machine is absolutely mind boggling. But nonetheless, those charges were levied against him. Ultimately,  the Department of Justice did not pursue those charges. Those charges were dropped. They went  ahead with other fraud charges. But nonetheless, for some period of time, he was facing computer  fraud and abuse act charges for doing exactly that. It's also worth looking at the tragic  case of Aaron Swartz who spoofed his MAC address to download journal articles. That was a  computer fraud and abuse act crime. Andrew Orenheimer who allegedly conspired to run  an automated script to plug in identifiers for iPads and get email addresses. Didn't  even do it himself. He's doing several years in federal prison for that. Also worth noting  that the Department of Justice has said in their manual about the computer fraud and  abuse act that conspiracy to hack a honeypot can violate the computer fraud and abuse act.  There's really no end to the sorts of things that could possibly violate the computer fraud  and abuse act. So you're looking at a situation where the computer fraud and abuse act almost  acts as an ex post facto law where the Department of Justice is able to look at what you did  after the fact. And if they don't like it or they don't like you for whatever reason,  you may be trollish for some reason. You are likely to be on the wrong end of a computer  fraud and abuse act prosecution. There's also a civil cause of action provided by the computer  fraud and abuse act. So the company that ‑‑ wherever the target is of this exploit can  also pursue whoever accessed the system without authorization. So the question then is what  can we ‑‑ is there anything we can do to try to reduce our chances of being on the  wrong end of this type of lawsuit? Well, let's take a quick ‑‑ we don't want to go too  far in a statute. It's not a continuing legal education conference. But let's take a quick  look at the statute and see if there's some key words we can at least identify. Here we  have whoever having knowingly accessed a computer without authorization. Another part of the  statute, whoever intentionally accesses a computer without authorization. So one of the  things you can do is to try to avoid unintentionally creating knowledge and intent. It's a little  bit hard to do this for yourself if you intend to do something. But at least you can avoid  doing it in connection with other people. So for example, I would suggest that you do  not direct information about how to use some kind of technique to someone that you suspect  or have reason to know is likely to use it illegally. Be careful in providing technical  support for some clever new technique that you've developed. So my advice, if I were  your lawyer, I would advise you not to answer that tweet. If someone is tweeting to you,  I would advise you to ask you about how to make something more effective, perhaps. This  slide is a little more detailed. Some more approaches that you might take. Don't provide  information possibly directly to individuals, especially if you're not sure who they are  or what they might be up to. Consider just posting things on a website only. Do not post  information to forums where you suspect or forums that are known to generally promote  illegal activity. If you publish it on your own website or you have control of the post,  consider disabling comments so you don't have a situation of people discussing potentially  illegal uses of your technique. And lastly, don't maintain logs. So one of the things  we've seen happen, that's enough for the computer fraud and abuse act for now. There's  not a whole lot you can really do about it beyond just being careful. Let's move on  to the temporary restraining order. This is particularly timely, actually, because you  may have read the story about the BW group and the megamos encryption that was used  on the vehicle immobilizers. So some European security researchers had figured out how to  bypass the ‑‑ or discover a flaw in the encryption that was used on the vehicle immobilizers  that were used in BW group cars like Porsche and Audi and Bentley. And they're going to  present this at the USNIX conference in Washington, D.C. in a few weeks. And they got themselves  slapped with a temporary restraining order preventing them from making this disclosure  at the conference. How did this happen? And how can we prevent this from happening again?  We've seen this here at DEF CON and Black Hat. The talks have been stopped by a temporary  restraining order. So take a quick look at the factors that the courts look at when  deciding whether or not to grant a temporary restraining order to prevent a researcher  from disclosing some information about a vulnerability. Number one, will the requester,  so in that case it would be the BW group, suffer irreparable harm if the TRO does not  issue. Good evening, sir. Who knows how this works? Is he a new speaker? It's really hard  to get accepted to speak at DEF CON. You should all be thinking about how you're going to  create speech talks. I've been drinking all day. Talks to eventually have yourselves up  here, right? A big round of applause for Jim. All right. One more order of business. We  need a new person who's first time at DEF CON. First hand up right there. Red shirt. Come  on up on the stage. We've got a little extra. Let's get one more. We're going to get two  people. All right. First hand up over there. There we go. All right. Cheers to our new  speaker. All right. Let's see if he can pick up where he left off. We're going to work  on new material for tomorrow. Thank you. Thanks, guys. All right. So that was great. Thank  you. So just a quick look at some of the factors that the court's going to look at when deciding  whether or not to grant the temporary training order. Will the requestor suffer irreparable  harm if the TRO does not issue? Pretty easy to imagine. You've got an embedded system  and someone's figured out how to break it. It's going to be almost impossible for them  to update it in any reasonable amount of time. Usually expensive. Probably some irreparable  harm. That basically means that money isn't going to fix it very easily. So that goes  in VW Group's favor. Will there be an even greater harm to the researcher if the TRO  does not issue? What your paper got delayed? You couldn't put in some part of the algorithm.  Maybe you had to pare it back. Hard to see that as a huge harm to the researcher. We  might feel really bad about that. But in terms of the use of money, VW Group is going to  have to pay to fix this. It's not really going to look too good for the researcher there.  The public interest is just kind of a fun one. Because we might think that, well, the  public interest clearly favors disclosing the vulnerability so it can be fixed. This  court's probably going to go the other way on that and see that really the risk to all  these BMWs or other Porsches and Bentley's and things being stolen is much greater, is  much more in the public interest than having your really obscure crypto talk go forward.  The last factor is the likelihood they request a role to mainly prevail. And this is really  the one we need to focus on. Because the VW Group has to have a cause of action. They  can't just say we don't like it. They have to say here's why you need to stop. And it's  because you did something bad to us. And in the case of the VW Group, the Megamos case,  and also in the case of the Cisco disclosure, what we had was the use of copyrighted material.  And that's really what ‑‑ that was the hook that got the TRO to issue. So the obvious  advice then is to avoid the use of copyrighted material. So if you include source code or  object code from whatever it is that you're working on, that gives leverage to whoever  it is that wants to stop you from disclosing it. There is a fair use exception if you use  little bits and pieces of code. That's a case by case analysis. And you can't just say,  well, this is going to be fair use. It depends on how much you use and other factors that  are very specific to what's actually going on in your case. So just try to avoid it if  you can. It may not be possible. But to the extent you can do that. Also avoid darknet  sources for wherever you're getting this stuff. In the Megamos case, the court actually  talked about the fact that the researchers obtained some information about how the Megamos  system worked through some sketchy channels. I don't recall it saying exactly where they  got it, but it was some sort of bit torrent, P2P type thing, wherever they got it. It wasn't  from a group or Megamos. So another thing you want to do is be aware of preexisting  contractual relationships that you as a security researcher might have with the target of  whatever it is you're working on. These contractual agreements could come in the form of a term  of service and use your license agreements, non‑disclosure agreements or employment  agreements. What's that?  An in‑user license agreement might very well have provisions in it that prohibit reverse  engineering software, for example. That's something you might be doing as part of your  exploration into your technique. That could give leverage to someone to try to stop using  oh, you've breached this. Nothing's for certain. It's just an argument that they have. It's  something ‑‑ there's not much you can do about it. Pretty much every piece of software  you get is going to have some kind of license agreement that's going to ‑‑ assuming  you came to it legitimately, right? You've agreed to this license that may prohibit you  from doing certain things with that software. There's not a whole lot you can do about  that. But you at least can be aware of the risk, if nothing else.  So how far you need to go in trying to mitigate the risk? Somewhat depends on the techniques  that you've used in your research. If you've done things that are clearly ‑‑ that clearly  look like some of the examples of what people have done that's gotten them prison time,  that's something you need to be careful of and maybe take more aggressive mitigation  techniques in order to perhaps hide some of the information about what you're doing.  So for example, if in the mega‑most case, no one had identified that it was the VW group  that was ‑‑ where this crypto system had been compromised, VW group would not have  been able to issue ‑‑ to go after a temporary restraining order against the researchers.  So perhaps there's an opportunity here for the conference‑going community to create  a track where people could present things that are sort of get like a little asterisk  or something next to it and we all recognize that this is something that had to be kept  quiet. It's sort of like a confidential disclosure, trust the review board, this is going to  be really cool, but we just can't really tell you about what it is because then you won't  get to hear it. So maybe that's one approach. So I'd like to talk about some of the ways  that you might make a disclosure that are relatively less likely to get you in trouble.  You can obviously disclose to the responsible party. That's what we'd like to do, that's  sort of what the responsible disclosure paradigm is all about. You found a problem with the  system, you tell who's running the system. This is actually unfortunately relatively  high risk and that risk scales with the questionableness of whatever technique it was that you used  to find out about this vulnerability. So if you're connected to the Internet, you access  the remote system and you have net permission, that's how you did it. It may not be a great  idea to go tell them about it because if they don't like it, they've got an action against  you. If you're inconvenient, that's a problem for you. You might think you're doing them  a favor. They might not agree that you're doing them a favor. If you're able to submit  it anonymously to whoever the vendor is or the responsible party, that's great. Depends  how good your Opsac is, I suppose. A lot of times you think you're maybe anonymous, but  you're not as anonymous as you thought you were or hoped you were. So that's a risk in  itself that you need to consider. If you submit to a bug bounty, presumably they've invited  it, maybe you're at less risk. You can disclose to a government authority, perhaps. Maybe  you don't really believe it, I'll ever get to the vendor. But again, if your techniques  were perhaps questionable, you might not necessarily want to be submitting it to a government,  a government authority. You may want to separately, you may have an interest in keeping your own  identity anonymous. Again, you can try to submit anonymously to the government, but I don't  know how much we can really trust that anymore. Fortunately ‑‑ this is a legal talk and  somewhat legal talking. You can almost never get to a legal talk where someone will actually  tell you something for sure. Like, absolutely, 100%, you will not get in trouble if you do  this. But fortunately, we are in a case here where there is one group of people who really  don't have to worry about getting in trouble with a computer front of use act when they  disclose the vulnerability and here they are. You know, okay to disclose if you're one of  these people. Although she really should not have been hacking the palace computer, we're  not going to hold that against her. So we're thinking about ways that we might be able  to leverage opportunities for security researchers to make disclosures while keeping the risk  as low as possible. So we're working on creating a pilot program where attorney client privilege  can be leveraged to hide the identity and techniques used by security researcher in  making a disclosure. So the concept works like this. The researcher would disclose the vulnerability  to a trusted third party, which would be an attorney, only to the attorney. It's critical  that this be a completely confidential disclosure to maintain the confidentiality of that disclosure  so that other entities on the outside can't get to it. The trusted third party does not  publish the vulnerability on behalf of the researcher. However, the trusted third party  does disclose the vulnerability to whoever the affected party is, whoever has this vulnerability.  The researcher remains anonymous during the entire process. This is possibly abuse if  there's no better option. It's a little bit cumbersome and there are some side effects  chiefly that the researcher remains anonymous, doesn't get public credit for whatever the  research was, but it is one possible way for the researcher to be able to disclose and remain  about as anonymous as one can possibly get. So this is a pilot program. We're currently  working on it. We're kicking out the bugs right now. So if anyone's interested in talking  to us further about this, we definitely welcome your input and please see me afterwards. We  should now turn to selling very quickly. Right now, there is no law in the U.S. that prohibits  the selling of an exploit. And that is a situation that is probably likely to change in the not  too distant future, but for now, there's really not too much to worry about unless the techniques  of course going back, if you're developing your exploit have some problem, then you still  have a problem. But the fact of the sale itself is not something that's going to get you in  trouble. However, there's a lot of focus on this market now. And here are some recent  articles from May of 2013, booming zero day trade as Washington experts worried. And my  favorite, the U.S. Senate wants to control malware like it's a missile. Stuff is dangerous.  So every year, the Congress has passed the National Defense Authorization Act. It sets  the budget for DOD and includes a bunch of other stuff that gets stuck in there. And  this year, well, for 2014, the Senate version, it hasn't been passed yet, it's still in Congress.  The Senate version has provisions that seek to begin the process of regulating the sale  of exploits. The bill, the House version doesn't have this. This is still just in the Senate.  But I think this is where it's headed. The bill notes that the President shall establish  a process for developing policy to control the proliferation of cyber weapons through  a whole series of possible actions, right? Export controls, law enforcement, financial,  diplomatic engagement, and so on. The Senate Armed Services Committee that had the bill  before it was passed to the rest of the Senate said they had some commentary on this. And  they referred to the dangerous software, a global black market, a gray market. It starts  to look really bad. But they note that there is ‑‑ we need to have a carve out for  dual use software and pen testing tools. In Europe, the European Parliament recently passed  a directive. They're a little bit ahead of us. This prohibition on the sale of tools,  as they call it, exploits, will be required to be enacted by all of the member states  in short order. And this provision prohibits the production, sale, procurement for use,  import, distribution of these tools that could be used to commit these enumerated defenses,  which is pretty much all the bad things that you can think of doing with a computer. However,  there's an exception. It's a very important exception. For tools that are created for  legitimate purposes, that's just to test the reliability of systems, and it further notes  that there needs to be ‑‑ in order to violate this law, you need to show a direct  intent that the tools be used to commit some of the offenses. So in both cases, both in  the U.S. and in Europe, we're seeing this trend, well, it's really going back to the  definitional problem. How do we define what an exploit is, and how do we make sure that  legitimate tools are ‑‑ can still be bought and sold? So this is kind of perspective.  We don't know what the laws are actually going to look like, but I would start thinking  like this. Think about dual‑use tools. If you write something, don't put it together  as the next greatest hack. You're creating pen testing tools. This has gone on for a  long time. If you look at software, I'm sure you all used it. Copy 2 plus, anybody? Backup  software. And the manuals for these software have these elaborate disclaimers. This is  strictly being used to back up your floppy. This is not being used to make illegal copies.  And that is really the conundrum. And I think that's where ‑‑ that's where exploits  will go. And some exploits will never be able to be looked at as a dual‑use tool for  sure. If you have a nuclear missile equivalent of an exploit, it's hard to justify the pen  testing value of that. But for a lot of tools, there is a will fall into this area. That's  where perhaps they should go. Some other things you might do if you are selling, know  your buyer to the extent you can. I think regulation is just one bad outcome  away. What's going to happen is someone in the U.S. is going to sell an exploit, go through  some channel, and come back and get used against some U.S. interests. We may not hear about  it. It may be a matter of, you know, maybe a secret. But this will happen. And then there  will be a huge drive to stop this from happening very quickly. It's the same reason, you know,  as soon as someone is murdered with a certain type of weapon, that weapon has to be banned,  that's going to happen here. The laws are created in this country is very reactionary.  And I expect that trend to continue here. So maybe you can prevent that from happening.  So know your buyer. If you're selling something, don't sell it to a channel where it's likely  to go to some country that's under an embargo with the United States. Maybe your best bet  is just to sell it to the U.S. As for assurances from your buyer, so you don't have knowledge  that is going to someplace where it's not supposed to go. You could be lied to, but  you can't control everything, right? But at least you can get an assurance that it's not  going to be used in some illegitimate way. And also, you could always use disclaimer  language. So I have some nice examples of disclaimer language here. This huge chunk  of text on the top is actually from a software product that many of you have probably used  many times. It's good stuff. I've highlighted probably the best of the operative language  in it. But if you're selling something, be sure to use some disclaimer language about  that kind of flows along these lines. That would help you from being charged and being  complicit in any sort of illegal use to which the software might eventually be put. And  lastly, I'd just like to highlight this bottom little paragraph, which is actually from the  Apple iTunes store. It's the end user license agreement that comes with that. And it requires  that you agree that you will not use these products for any purpose prohibited by the  United States law, including without limitation, to development design, manufacture, production  of nuclear missiles or chemical or biological weapons. Thank God. Words with friends. That  is dangerous stuff. So thank you for coming. This is my contact block. So I think we have  some time here for questions. So if people want to line up, I'm happy to entertain them  as best we can.  There are definitely free speech issues, especially in the temporary restraining order context.  Oh, second amendment, sorry. Second amendment challenge? Come see me after about that.  Question back here.  Question.  Let's connect on that. Let's connect on that.  Okay.  So what about using a corporation to limit your liability for disclosure or selling? Is  that been utilized?  Corporations can be held liable in many cases. In fact, even under the computer fraud and  hasn't happened yet, but a corporation could be held liable.  Done?  Question regarding full disclosure versus responsible disclosure. So when we do it, we do it via  responsible disclosure. We contact a vendor, we give them 30 days and we tell them our intent  to publish and we publish everything. So the actual vulnerability and how to do it so that  they can replicate and do whatever they want. In most cases, the vendors get a hot fix within  a week and then if within 30 days they provide the hot fix, we spread them and say, you know,  to fix it, install hot fix, whatever. Sometimes vendors will say we need more time, maybe we'll  negotiate a couple of days, but sometimes they'll say we're not going to fix it and you can't  publish it. So I won't explain what we do for that. But Google recently published the fact  that they plan to disclose vulnerabilities within seven days, all right, to have a seven-day  turnaround. So what happens if a company like Google, I don't know if these are worth  threatening, but intends to publish a vulnerability within the seven-day turnaround period and  that company says to Google, don't, if you do, we'll sue you. What happens in Google versus  that vendor company?  Well, Google is at risk if Google has some kind of obligation not to. I mean, if, it would  depend on the specific circumstances of it, but in this case, I mean, if no law has been  broken, then Google could be published without any caution.  In the case for me, for example, where I contact a vendor and I say I've got the following ten  vulnerabilities which I plan to publish and they come back to me and say, if you publish  those, we'll sue you, right? And the same thing happens when Google say, well, we're not going  to give you 30 days, we're going to give you seven days and the company comes back and  says, Google, we're going to sue you if you publish. It doesn't carry the same weight where  they're trying to sue Google as they're trying to sue me, for example.  That helps as well, man.  I mean, that's the unfortunate part. I mean, as a...  But is it just a case of how good your legal team is, how expensive your legal team is?  Exactly.  How much do you charge?  Where do you want to meet them at?  Let's go.  Where's good?  Wherever you want to meet them at to carry on because it's about five or six other people.  It's on the hall.  So this talks over with. We've got to get it ready for the evening. Now on the hallway,  we'll answer the rest of your questions. Unfortunately, there's not a Q&A because it's been  disassembled too.  Thank you all.  Thank you.
DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_0_731.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_732_1535.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_1536_2627.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_2628_2975.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_2976_4415.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_4416_4907.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_4908_5735.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_5736_6299.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_6300_6395.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_6396_7967.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_7968_9347.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_9348_10871.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_10872_15767.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_15768_16511.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_16512_16679.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_16680_17147.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_17148_17519.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_17520_17939.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_17940_19079.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_19080_21335.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_21336_21407.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_21408_26159.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_26160_26207.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_26208_28307.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_28308_30059.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_30060_32123.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_32124_32171.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_32172_32231.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_32232_32279.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_32280_32327.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_32328_34163.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_34164_34835.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_34836_35579.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_35580_35819.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_35820_38771.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_38772_40091.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_40092_41435.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_41436_42167.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_42168_43043.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_43044_43895.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_43896_47663.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_47664_49163.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_49164_50015.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50016_50207.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50208_50471.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50472_50711.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50712_50759.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50760_50807.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_50808_54443.png DEF_CON_21_-_James_Denaro_-_How_to_Disclose_or_Sell_an_Exploit_N1Xj3f4felg_54444_55447.png
So the topic for today is how to disclose or sell an exploit without getting in trouble. I'm Jim Dinaro. I'm an intellectual property attorney based out of Washington, D.C. I focus my work exclusively on information security technologies. Before I went to law school, I used to spend far too much time just tweaking around on MaxBug on my power PC and figured that no better way to keep doing that than to do this. So here we go. Just 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 that this presentation is not legal advice about your specific situation or your specific questions. Even if you ask me a question, we're 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 an attorney-client relationship alone. We can maybe do that later. So this is a quick overview of what we're trying to accomplish here in the next 20 minutes. I'm going to speak quickly to make sure we get it all in. We're going to cover the types of risks that are being faced by researchers, some risk mitigation strategies that researchers can take to try to reduce those risks, some of your options for disclosing a vulnerability that may be less ‑‑ 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, well, 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's 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. So let's start out with just some great examples of the kind of research activities that might get somebody in trouble. For example, some of these are generally real life cases. You found out how to see other people's utility bills by changing the HTTP query string. I talked to someone at a party the other night who had done just exactly that. He was wondering what to do about it. You discover your neighbor's Wi‑Fi is not protected. How did you find that out? You broke the crypto that's protecting some media that you had. It's getting a little more serious now. There's actual money at stake. And maybe you wrote a better remote access tool. That sounds like you might make a lot of money. So many of the same risks apply, surprisingly enough, whether you're just looking at changing HTTP strings or whether you're actually taking apart a DVD. So in general, we're talking about techniques. I've sort of defined it here. Broad spectrum, everything from denial of service, a technique that might be used for denial of service attacks to something that's just, you know, more akin to sort of investigatory web browsing. Okay. First, when is there risk to a security researcher? There are three general areas where we see the risk starting to show up. One, there can be a threat of legal action before you go to a conference or make this disclosure. There are some examples listed here. You might be the recipient of a legal action seeking an injunction barring you from disclosing something before a conference. So we now remove from merely saber rattling to an actual lawsuit being filed against you. And then there's the possibility of a legal action being initiated against you after you make the disclosure. And these are all real examples. You can, Declan McCulloch of CNET and his colleagues have written some very interesting articles that go into more detail about some of these cases. I would recommend them to you most definitely. But you might notice that some of these seem to be around black cat and deaf con on a pretty regular basis. So that's when it can happen. Your number one concern is typically going to be the computer front and view sacked. You probably heard a lot about that lately, perhaps here 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 your, 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. So in light of, you know, everyone's talked much about how vague this notion of computer fraud and abuse act is of authorization. I've created a handy checklist to figure out if you might have a computer fraud and abuse act problem. So there we 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 a 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 this sort of like the Andrew Orinheimer situation where he's querying a public-facing API on a repeated basis. No one asked him to do that. But there was no banner. There was no clear prohibition of doing that. It was a public-facing API, after all. So there's really some real risk in figuring out if you can ‑‑ whether or not you have permission. But that's really all it takes. 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 most certainly enhanced by the prevalence of social media today. So if you're on Twitter or some other easy, 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 is not. But if you start providing technical support for something that someone else is doing, you're really definitely increasing the risk of being caught up in a conspiracy to violate the computer fraud and abuse act if not actually violating yourself. So we've got some examples here where computer fraud and abuse act has been applied. I think it's helpful to look at some examples because that's how we see how it's being applied. And we can compare what we're doing to some of the things that have happened in the past, other people, and see how close those comparisons are. And since we're in Las Vegas, we absolutely have to talk about the case of Nestor. Nestor was really into video poker. And he liked to play and play and play and play. And he got really good at it. And he played it so much that he discovered a bug in the video poker software that enabled him to play one type of game and bid up a bunch of money into that game and then switch to a different game and a multiplier would be applied to his bid. So when he won, he got this enormous payout. And he figured out how to reproduce this bug very efficiently. So he was doing it and his friends were doing it and they were getting a lot of money. And obviously eventually, how these stories always end, he gets caught. And he was charged with, amongst other frauds, violating the computer fraud and abuse act. And as we were just looking at the computer fraud and abuse act a few moments ago, we saw it's really mostly about unauthorized access or exceeding an authorization that you had. And it's hard to imagine how sitting ‑‑ he didn't access the firmware, he didn't take the game apart, he just sat there putting money in and pushing the buttons on the surface of the machine. How you could exceed authorized access to a video poker machine is absolutely mind boggling. But nonetheless, those charges were levied against him. Ultimately, the Department of Justice did not pursue those charges. Those charges were dropped. They went ahead with other fraud charges. But nonetheless, for some period of time, he was facing computer fraud and abuse act charges for doing exactly that. It's also worth looking at the tragic case of Aaron Swartz who spoofed his MAC address to download journal articles. That was a computer fraud and abuse act crime. Andrew Orenheimer who allegedly conspired to run an automated script to plug in identifiers for iPads and get email addresses. Didn't even do it himself. He's doing several years in federal prison for that. Also worth noting that the Department of Justice has said in their manual about the computer fraud and abuse act that conspiracy to hack a honeypot can violate the computer fraud and abuse act. There's really no end to the sorts of things that could possibly violate the computer fraud and abuse act. So you're looking at a situation where the computer fraud and abuse act almost acts as an ex post facto law where the Department of Justice is able to look at what you did after the fact. And if they don't like it or they don't like you for whatever reason, you may be trollish for some reason. You are likely to be on the wrong end of a computer fraud and abuse act prosecution. There's also a civil cause of action provided by the computer fraud and abuse act. So the company that ‑‑ wherever the target is of this exploit can also pursue whoever accessed the system without authorization. So the question then is what can we ‑‑ is there anything we can do to try to reduce our chances of being on the wrong end of this type of lawsuit? Well, let's take a quick ‑‑ we don't want to go too far in a statute. It's not a continuing legal education conference. But let's take a quick look at the statute and see if there's some key words we can at least identify. Here we have whoever having knowingly accessed a computer without authorization. Another part of the statute, whoever intentionally accesses a computer without authorization. So one of the things you can do is to try to avoid unintentionally creating knowledge and intent. It's a little bit hard to do this for yourself if you intend to do something. But at least you can avoid doing it in connection with other people. So for example, I would suggest that you do not direct information about how to use some kind of technique to someone that you suspect or have reason to know is likely to use it illegally. Be careful in providing technical support for some clever new technique that you've developed. So my advice, if I were your lawyer, I would advise you not to answer that tweet. If someone is tweeting to you, I would advise you to ask you about how to make something more effective, perhaps. This slide is a little more detailed. Some more approaches that you might take. Don't provide information possibly directly to individuals, especially if you're not sure who they are or what they might be up to. Consider just posting things on a website only. Do not post information to forums where you suspect or forums that are known to generally promote illegal activity. If you publish it on your own website or you have control of the post, consider disabling comments so you don't have a situation of people discussing potentially illegal uses of your technique. And lastly, don't maintain logs. So one of the things we've seen happen, that's enough for the computer fraud and abuse act for now. There's not a whole lot you can really do about it beyond just being careful. Let's move on to the temporary restraining order. This is particularly timely, actually, because you may have read the story about the BW group and the megamos encryption that was used on the vehicle immobilizers. So some European security researchers had figured out how to bypass the ‑‑ or discover a flaw in the encryption that was used on the vehicle immobilizers that were used in BW group cars like Porsche and Audi and Bentley. And they're going to present this at the USNIX conference in Washington, D.C. in a few weeks. And they got themselves slapped with a temporary restraining order preventing them from making this disclosure at the conference. How did this happen? And how can we prevent this from happening again? We've seen this here at DEF CON and Black Hat. The talks have been stopped by a temporary restraining order. So take a quick look at the factors that the courts look at when deciding whether or not to grant a temporary restraining order to prevent a researcher from disclosing some information about a vulnerability. Number one, will the requester, so in that case it would be the BW group, suffer irreparable harm if the TRO does not issue. Good evening, sir. Who knows how this works? Is he a new speaker? It's really hard to get accepted to speak at DEF CON. You should all be thinking about how you're going to create speech talks. I've been drinking all day. Talks to eventually have yourselves up here, right? A big round of applause for Jim. All right. One more order of business. We need a new person who's first time at DEF CON. First hand up right there. Red shirt. Come on up on the stage. We've got a little extra. Let's get one more. We're going to get two people. All right. First hand up over there. There we go. All right. Cheers to our new speaker. All right. Let's see if he can pick up where he left off. We're going to work on new material for tomorrow. Thank you. Thanks, guys. All right. So that was great. Thank you. So just a quick look at some of the factors that the court's going to look at when deciding whether or not to grant the temporary training order. Will the requestor suffer irreparable harm if the TRO does not issue? Pretty easy to imagine. You've got an embedded system and someone's figured out how to break it. It's going to be almost impossible for them to update it in any reasonable amount of time. Usually expensive. Probably some irreparable harm. That basically means that money isn't going to fix it very easily. So that goes in VW Group's favor. Will there be an even greater harm to the researcher if the TRO does not issue? What your paper got delayed? You couldn't put in some part of the algorithm. Maybe you had to pare it back. Hard to see that as a huge harm to the researcher. We might feel really bad about that. But in terms of the use of money, VW Group is going to have to pay to fix this. It's not really going to look too good for the researcher there. The public interest is just kind of a fun one. Because we might think that, well, the public interest clearly favors disclosing the vulnerability so it can be fixed. This court's probably going to go the other way on that and see that really the risk to all these BMWs or other Porsches and Bentley's and things being stolen is much greater, is much more in the public interest than having your really obscure crypto talk go forward. The last factor is the likelihood they request a role to mainly prevail. And this is really the one we need to focus on. Because the VW Group has to have a cause of action. They can't just say we don't like it. They have to say here's why you need to stop. And it's because you did something bad to us. And in the case of the VW Group, the Megamos case, and also in the case of the Cisco disclosure, what we had was the use of copyrighted material. And that's really what ‑‑ that was the hook that got the TRO to issue. So the obvious advice then is to avoid the use of copyrighted material. So if you include source code or object code from whatever it is that you're working on, that gives leverage to whoever it is that wants to stop you from disclosing it. There is a fair use exception if you use little bits and pieces of code. That's a case by case analysis. And you can't just say, well, this is going to be fair use. It depends on how much you use and other factors that are very specific to what's actually going on in your case. So just try to avoid it if you can. It may not be possible. But to the extent you can do that. Also avoid darknet sources for wherever you're getting this stuff. In the Megamos case, the court actually talked about the fact that the researchers obtained some information about how the Megamos system worked through some sketchy channels. I don't recall it saying exactly where they got it, but it was some sort of bit torrent, P2P type thing, wherever they got it. It wasn't from a group or Megamos. So another thing you want to do is be aware of preexisting contractual relationships that you as a security researcher might have with the target of whatever it is you're working on. These contractual agreements could come in the form of a term of service and use your license agreements, non‑disclosure agreements or employment agreements. What's that? An in‑user license agreement might very well have provisions in it that prohibit reverse engineering software, for example. That's something you might be doing as part of your exploration into your technique. That could give leverage to someone to try to stop using oh, you've breached this. Nothing's for certain. It's just an argument that they have. It's something ‑‑ there's not much you can do about it. Pretty much every piece of software you get is going to have some kind of license agreement that's going to ‑‑ assuming you came to it legitimately, right? You've agreed to this license that may prohibit you from doing certain things with that software. There's not a whole lot you can do about that. But you at least can be aware of the risk, if nothing else. So how far you need to go in trying to mitigate the risk? Somewhat depends on the techniques that you've used in your research. If you've done things that are clearly ‑‑ that clearly look like some of the examples of what people have done that's gotten them prison time, that's something you need to be careful of and maybe take more aggressive mitigation techniques in order to perhaps hide some of the information about what you're doing. So for example, if in the mega‑most case, no one had identified that it was the VW group that was ‑‑ where this crypto system had been compromised, VW group would not have been able to issue ‑‑ to go after a temporary restraining order against the researchers. So perhaps there's an opportunity here for the conference‑going community to create a track where people could present things that are sort of get like a little asterisk or something next to it and we all recognize that this is something that had to be kept quiet. It's sort of like a confidential disclosure, trust the review board, this is going to be really cool, but we just can't really tell you about what it is because then you won't get to hear it. So maybe that's one approach. So I'd like to talk about some of the ways that you might make a disclosure that are relatively less likely to get you in trouble. You can obviously disclose to the responsible party. That's what we'd like to do, that's sort of what the responsible disclosure paradigm is all about. You found a problem with the system, you tell who's running the system. This is actually unfortunately relatively high risk and that risk scales with the questionableness of whatever technique it was that you used to find out about this vulnerability. So if you're connected to the Internet, you access the remote system and you have net permission, that's how you did it. It may not be a great idea to go tell them about it because if they don't like it, they've got an action against you. If you're inconvenient, that's a problem for you. You might think you're doing them a favor. They might not agree that you're doing them a favor. If you're able to submit it anonymously to whoever the vendor is or the responsible party, that's great. Depends how good your Opsac is, I suppose. A lot of times you think you're maybe anonymous, but you're not as anonymous as you thought you were or hoped you were. So that's a risk in itself that you need to consider. If you submit to a bug bounty, presumably they've invited it, maybe you're at less risk. You can disclose to a government authority, perhaps. Maybe you don't really believe it, I'll ever get to the vendor. But again, if your techniques were perhaps questionable, you might not necessarily want to be submitting it to a government, a government authority. You may want to separately, you may have an interest in keeping your own identity anonymous. Again, you can try to submit anonymously to the government, but I don't know how much we can really trust that anymore. Fortunately ‑‑ this is a legal talk and somewhat legal talking. You can almost never get to a legal talk where someone will actually tell you something for sure. Like, absolutely, 100%, you will not get in trouble if you do this. But fortunately, we are in a case here where there is one group of people who really don't have to worry about getting in trouble with a computer front of use act when they disclose the vulnerability and here they are. You know, okay to disclose if you're one of these people. Although she really should not have been hacking the palace computer, we're not going to hold that against her. So we're thinking about ways that we might be able to leverage opportunities for security researchers to make disclosures while keeping the risk as low as possible. So we're working on creating a pilot program where attorney client privilege can be leveraged to hide the identity and techniques used by security researcher in making a disclosure. So the concept works like this. The researcher would disclose the vulnerability to a trusted third party, which would be an attorney, only to the attorney. It's critical that this be a completely confidential disclosure to maintain the confidentiality of that disclosure so that other entities on the outside can't get to it. The trusted third party does not publish the vulnerability on behalf of the researcher. However, the trusted third party does disclose the vulnerability to whoever the affected party is, whoever has this vulnerability. The researcher remains anonymous during the entire process. This is possibly abuse if there's no better option. It's a little bit cumbersome and there are some side effects chiefly that the researcher remains anonymous, doesn't get public credit for whatever the research was, but it is one possible way for the researcher to be able to disclose and remain about as anonymous as one can possibly get. So this is a pilot program. We're currently working on it. We're kicking out the bugs right now. So if anyone's interested in talking to us further about this, we definitely welcome your input and please see me afterwards. We should now turn to selling very quickly. Right now, there is no law in the U.S. that prohibits the selling of an exploit. And that is a situation that is probably likely to change in the not too distant future, but for now, there's really not too much to worry about unless the techniques of course going back, if you're developing your exploit have some problem, then you still have a problem. But the fact of the sale itself is not something that's going to get you in trouble. However, there's a lot of focus on this market now. And here are some recent articles from May of 2013, booming zero day trade as Washington experts worried. And my favorite, the U.S. Senate wants to control malware like it's a missile. Stuff is dangerous. So every year, the Congress has passed the National Defense Authorization Act. It sets the budget for DOD and includes a bunch of other stuff that gets stuck in there. And this year, well, for 2014, the Senate version, it hasn't been passed yet, it's still in Congress. The Senate version has provisions that seek to begin the process of regulating the sale of exploits. The bill, the House version doesn't have this. This is still just in the Senate. But I think this is where it's headed. The bill notes that the President shall establish a process for developing policy to control the proliferation of cyber weapons through a whole series of possible actions, right? Export controls, law enforcement, financial, diplomatic engagement, and so on. The Senate Armed Services Committee that had the bill before it was passed to the rest of the Senate said they had some commentary on this. And they referred to the dangerous software, a global black market, a gray market. It starts to look really bad. But they note that there is ‑‑ we need to have a carve out for dual use software and pen testing tools. In Europe, the European Parliament recently passed a directive. They're a little bit ahead of us. This prohibition on the sale of tools, as they call it, exploits, will be required to be enacted by all of the member states in short order. And this provision prohibits the production, sale, procurement for use, import, distribution of these tools that could be used to commit these enumerated defenses, which is pretty much all the bad things that you can think of doing with a computer. However, there's an exception. It's a very important exception. For tools that are created for legitimate purposes, that's just to test the reliability of systems, and it further notes that there needs to be ‑‑ in order to violate this law, you need to show a direct intent that the tools be used to commit some of the offenses. So in both cases, both in the U.S. and in Europe, we're seeing this trend, well, it's really going back to the definitional problem. How do we define what an exploit is, and how do we make sure that legitimate tools are ‑‑ can still be bought and sold? So this is kind of perspective. We don't know what the laws are actually going to look like, but I would start thinking like this. Think about dual‑use tools. If you write something, don't put it together as the next greatest hack. You're creating pen testing tools. This has gone on for a long time. If you look at software, I'm sure you all used it. Copy 2 plus, anybody? Backup software. And the manuals for these software have these elaborate disclaimers. This is strictly being used to back up your floppy. This is not being used to make illegal copies. And that is really the conundrum. And I think that's where ‑‑ that's where exploits will go. And some exploits will never be able to be looked at as a dual‑use tool for sure. If you have a nuclear missile equivalent of an exploit, it's hard to justify the pen testing value of that. But for a lot of tools, there is a will fall into this area. That's where perhaps they should go. Some other things you might do if you are selling, know your buyer to the extent you can. I think regulation is just one bad outcome away. What's going to happen is someone in the U.S. is going to sell an exploit, go through some channel, and come back and get used against some U.S. interests. We may not hear about it. It may be a matter of, you know, maybe a secret. But this will happen. And then there will be a huge drive to stop this from happening very quickly. It's the same reason, you know, as soon as someone is murdered with a certain type of weapon, that weapon has to be banned, that's going to happen here. The laws are created in this country is very reactionary. And I expect that trend to continue here. So maybe you can prevent that from happening. So know your buyer. If you're selling something, don't sell it to a channel where it's likely to go to some country that's under an embargo with the United States. Maybe your best bet is just to sell it to the U.S. As for assurances from your buyer, so you don't have knowledge that is going to someplace where it's not supposed to go. You could be lied to, but you can't control everything, right? But at least you can get an assurance that it's not going to be used in some illegitimate way. And also, you could always use disclaimer language. So I have some nice examples of disclaimer language here. This huge chunk of text on the top is actually from a software product that many of you have probably used many times. It's good stuff. I've highlighted probably the best of the operative language in it. But if you're selling something, be sure to use some disclaimer language about that kind of flows along these lines. That would help you from being charged and being complicit in any sort of illegal use to which the software might eventually be put. And lastly, I'd just like to highlight this bottom little paragraph, which is actually from the Apple iTunes store. It's the end user license agreement that comes with that. And it requires that you agree that you will not use these products for any purpose prohibited by the United States law, including without limitation, to development design, manufacture, production of nuclear missiles or chemical or biological weapons. Thank God. Words with friends. That is dangerous stuff. So thank you for coming. This is my contact block. So I think we have some time here for questions. So if people want to line up, I'm happy to entertain them as best we can. There are definitely free speech issues, especially in the temporary restraining order context. Oh, second amendment, sorry. Second amendment challenge? Come see me after about that. Question back here. Question. Let's connect on that. Let's connect on that. Okay. So what about using a corporation to limit your liability for disclosure or selling? Is that been utilized? Corporations can be held liable in many cases. In fact, even under the computer fraud and hasn't happened yet, but a corporation could be held liable. Done? Question regarding full disclosure versus responsible disclosure. So when we do it, we do it via responsible disclosure. We contact a vendor, we give them 30 days and we tell them our intent to publish and we publish everything. So the actual vulnerability and how to do it so that they can replicate and do whatever they want. In most cases, the vendors get a hot fix within a week and then if within 30 days they provide the hot fix, we spread them and say, you know, to fix it, install hot fix, whatever. Sometimes vendors will say we need more time, maybe we'll negotiate a couple of days, but sometimes they'll say we're not going to fix it and you can't publish it. So I won't explain what we do for that. But Google recently published the fact that they plan to disclose vulnerabilities within seven days, all right, to have a seven-day turnaround. So what happens if a company like Google, I don't know if these are worth threatening, but intends to publish a vulnerability within the seven-day turnaround period and that company says to Google, don't, if you do, we'll sue you. What happens in Google versus that vendor company? Well, Google is at risk if Google has some kind of obligation not to. I mean, if, it would depend on the specific circumstances of it, but in this case, I mean, if no law has been broken, then Google could be published without any caution. In the case for me, for example, where I contact a vendor and I say I've got the following ten vulnerabilities which I plan to publish and they come back to me and say, if you publish those, we'll sue you, right? And the same thing happens when Google say, well, we're not going to give you 30 days, we're going to give you seven days and the company comes back and says, Google, we're going to sue you if you publish. It doesn't carry the same weight where they're trying to sue Google as they're trying to sue me, for example. That helps as well, man. I mean, that's the unfortunate part. I mean, as a... But is it just a case of how good your legal team is, how expensive your legal team is? Exactly. How much do you charge? Where do you want to meet them at? Let's go. Where's good? Wherever you want to meet them at to carry on because it's about five or six other people. It's on the hall. So this talks over with. We've got to get it ready for the evening. Now on the hallway, we'll answer the rest of your questions. Unfortunately, there's not a Q&A because it's been disassembled too. Thank you all. Thank you.
an exploit without getting in trouble. I'm Jim Dinaro. I'm an intellectual property attorney exclusively on information security technologies. Just because I'm an attorney and this does have advice about your specific situation or your sure we get it all in. We're going to cover the types of risks that are being faced by risks, some of your options for disclosing a vulnerability that may be less ‑‑ that may have associated with selling an exploit. The overall about it. You discover your neighbor's Wi‑Fi is There are some examples listed here. You might be the recipient of a legal action seeking an increasing the risk of being caught up in a for some period of time, he was facing computer that. It's also worth looking at the tragic case to reduce our chances of being on the wrong end use and other factors that are very specific to on the techniques that you've used in your risk and that risk scales with the submit it anonymously to whoever the vendor is or consider. If you submit to a bug bounty, security researchers to make disclosures while this is a pilot program. We're currently working So every year, the Congress has passed the before it was passed to the rest of the Senate sale of tools, as they call it, exploits, will be use, import, distribution of these tools that This has gone on for a long time. If you look at little paragraph, which is actually from the States law, including without limitation, to the actual vulnerability and how to do it so that