Quantcast

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

Elaborating on the Computer Fraud and Abuse Act as well as temporary restraining orders, James Denaro now advises on ways of mitigating the respective risks.

Cases where CFAA has been applied

Cases where CFAA has been applied

We’ve got some examples here (see right-hand image) where CFAA 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 to 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. He got really good at it. 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 bet a bunch of money in that game, and then switch to a different game, and multiplier would be applied to his bet. So, when he won he got to see 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 Computer Fraud and Abuse Act.

As we were looking at CFAA 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 setting hidden access to firmware – he didn’t take the game apart, he just sat there putting money in and pushing the buttons on the surface of 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.

Conspiracy to hack a honeypot can violate the CFAA.

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 Auernheimer who allegedly conspired to run an automated script to plug in identifiers for iPads and get email addresses. He’s doing several years in federal prison for that.

Also worth noting that Department of Justice has said in their manual about Computer Fraud and Abuse Act that conspiracy to hack a honeypot can violate the CFAA. There’s really no end to the sorts of things that can possibly violate the CFAA. 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 if they don’t like you for whatever reason, you are likely to be on the wrong end of CFAA prosecution. There’s also civil cause of action provided by the Computer Fraud and Abuse Act, so the company that’s the target of this exploit can also pursue who has ever accessed the system without authorization.

Mitigating CFAA risks

Mitigating CFAA risks

So, the question is whether there’s anything we can do to try to reduce our chances of being on the wrong end of this type of lawsuit. We don’t want to go too far in the statute, but let’s see some keywords we can obviously identify. Here we have: “Whoever – having knowingly accessed a computer without authorization”. Another part of the statute: “Whoever – intentionally accesses a computer without authorization”.

Another thing to avoid

Another thing to avoid

One of the things you can do is 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.

Be careful with untrustworthy people

Be careful with untrustworthy people

For example, I always suggested 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.

Provide 'support' with caution

Provide ‘support’ with caution

Be careful in providing technical support for some clever new technique that you developed. So, if I were your lawyer I would advise you not to answer that tweet if someone’s tweeting to you asking you about how to make something more effective perhaps.

More precautions regarding the CFAA

More precautions regarding the CFAA

This slide (see left-hand image) is a little more detailed, some more approaches that you might take. Do not provide information directly to individuals, especially if you’re not sure who they are or what they might be up to; consider posting things on a website only. Do not post information to forums that are generally known to 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, 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.

TRO factors to take into account

TRO factors to take into account

Let’s move on to temporary restraining order (TRO). This is particularly timely, actually, because you may have read the story about the VW Group and the Megamos encryption that was used on the vehicle immobilizers. So, some European security researchers had discovered a flaw in the encryption that was used on the vehicle immobilizers that were used on VW Group cars, like Porsche, Audi, and Bentley, and they were going to present this at the USENIX conference in Washington, D.C. in a few weeks, and they got themselves flapped with a temporary restraining order preventing them from presenting their findings at the conference.

How did it happen and how do we prevent this from happening again? We’ve seen this here at Defcon and at Black Hat, where talks have been stopped by a temporary restraining order. So, take a quick look at the factors (see right-hand image above) that the courts look at when deciding whether or not to grant a TRO to prevent a researcher from disclosing some information about a vulnerability.

#1: will the requestor – in that case it would be the VW Group – suffer irreparable harm if the TRO does not issue? Pretty easy to imagine you’ve got an embedded system and someone has figured out how to break it. It’s going to be almost impossible for them to update it within a reasonable amount of time, and it’s usually expensive. Basically, “irreparable harm” means that money isn’t going to fix it very easily. So, that goes in VW Group’s favor.

#2: will there be an even greater harm to the researcher if the TRO does issue? Your paper got delayed – hard to see that as a huge harm to the researcher. We might feel really bad about that, but in terms of the sums of money the VW Group is going to have to pay to fix this, it’s not really put too good for the researcher there.

#3: the public interest. This is kind of a fun one because we might think that while the public interest clearly favors disclosing the vulnerability so that it can be fixed, the court is probably going to go the other way on that and see that all risk to VW’s Porsches and Betleys being stolen is much more in the public interest than having your really obscure crypto talk go forward.

Avoid using copyrighted material

Avoid using copyrighted material

The last factor is the likelihood a requestor will ultimately prevail. This is really the one we need to focus on because the VW Group has to have a cause of action. They came to see we don’t like it. They have to say: “Here’s why you need to stop: it’s because you did something bad to us.” And in the case of the VW Group, in the Megamos case, and also in the case of the Cisco disclosure, what we had was the use of copyrighted material. 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 are 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, but you can’t just say: “Well, this is going to be fair use.” It matters how much you use and other factors that are very specific what is actually going on in your case. 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 exactly where they got it, but it was some sort of BitTorrent P2P type thing, it wasn’t from VW Group or Megamos.
 

Read previous: How to Disclose or Sell an Exploit without Getting in Trouble

Read next: How to Disclose or Sell an Exploit without Getting in Trouble 3: Minimizing Disclosure Problems

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

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

Comment via Facebook: