Don't Get Arrested

Start HerePage 2 of 415 minutesLessonNo lab next

Crime is not a career plan

You know the hacker who breaks into a government system, gets caught, and turns out to be so impressive that someone offers them a job? That’s fake. The TV is lying to you.

If you want to be hired on as a hacker, you are looking for a job in the SECURITY field. Making a habit of violating the security of other people isn’t a good look.

That isn’t to say you shouldn’t be researching things on your own. There are plenty of targets out there, and the scope of what you are allowed to do is surprisingly wide. That said, if you’re going to be doing this, you should have a decent understanding of the relevant laws in your country so you don’t get arrested by accident. It would be embarrassing to get fired or end up in jail because you were trying to screw with your neighbor’s lights.

Learning objectives

By the end of this lesson

• Explain what authorized access means in practice.
• Recognize when permission does not cover the research you want to perform.
• Identify the targets that are safe to use throughout this course.
• Explain the limits of device ownership and publishing research.

Permission is the boundary

I’m going to focus on US law on this page because that’s where I’m from and it’s the law I know the best. Even if you’re not from the US this will likely be helpful, but you should look into your country’s laws as well once you’re done here.

The main federal law you’ll hear about is the Computer Fraud and Abuse Act, or CFAA. It covers several computer crimes, including accessing systems without authorization. Depending on what happened, a violation can mean prison time or a lawsuit. This is worth getting right.

This page isn’t personal legal advice, and the CFAA isn’t the only law that can apply. For our purposes, start here: get permission from someone who has the authority to give it before testing their system.

Safety note

Public does not mean authorized

Being able to reach a system over the internet doesn’t give you permission to test it. Check who owns it and whether they’ve actually invited that kind of work.

What authorized access means

Authorization means you’ve been given permission to access a system. The owner can give it, or someone acting on their behalf can, but there’s usually a limit to what they’re agreeing to.

Creating an account on a website, for example, lets you use your account. It doesn’t make everyone else’s account fair game. Even permission to do security testing has limits: being allowed to scan a server doesn’t necessarily mean you can download whatever you find on it.

Those limits are the scope of the work. If you’re working on someone else’s system, get the scope in writing before starting, because “you can test our app” leaves a lot for you and the owner to disagree about later. You want to know which systems are included and what you’re allowed to do to them.

One legal detail is worth separating from that advice. The CFAA’s exceeding authorized access provision concerns getting into parts of a computer you’re not allowed to access. The Supreme Court explained in Van Buren v. United States that misusing information you were allowed to access isn’t enough, by itself, to commit that particular offense. Not every broken rule is a CFAA violation.

That doesn’t make ignoring the agreed scope a good idea. If permission is missing, unclear, or withdrawn, stop and ask whoever can authorize the work. Ask before running the test, not while it’s running.

Researching your own hardware

Suppose you buy a smart light bulb because you want to take apart its software. You find a weakness, write a small program that uses it, and demonstrate the result on your bulb. That program is an exploit, and doing this on your own device is lawful research. You’ve got a real piece of software to investigate without needing access to anyone else’s equipment.

Now suppose your neighbor has the same bulb. Your program might work on theirs too, but buying yours didn’t give you permission to try it on theirs. They may have bought it for the rather less ambitious purpose of lighting their kitchen, and you’ll need to ask before involving it in your research.

The manufacturer’s cloud service is a little less obvious. You might need an account there just to turn the bulb on. Does buying the bulb let you test those servers too? No. You bought a bulb, not the manufacturer’s servers. Sending your tests through the bulb doesn’t change that, so keep them on equipment and networks you control unless you’ve arranged permission to go further.

Owning the bulb doesn’t settle every legal question, either. If you need to bypass software access controls, the Digital Millennium Copyright Act (DMCA) can apply. It has a security-research exemption, but read its conditions before relying on it: the research must be in good faith, avoid harm, and use the findings primarily to improve security or safety. Other laws still apply.

You bought the bulb

• Owned by you

  Your bulb

  Your device to investigate, subject to the applicable laws.

• Owned by the manufacturer

  The cloud service

  Testing these servers needs separate authorization.

• Owned by your neighbor

  Their bulb

  Same model. Different owner. Ask before testing it.

↔ Your bulb connects to the manufacturer's service. That connection doesn't extend your permission to its servers.

Publishing what you find

Once you’ve figured out what’s wrong with the bulb, you may want to write about it. That’s a normal part of research, and explaining a flaw isn’t the same thing as using it on someone else’s device. You can publish research lawfully, but pay attention to what you’re actually sharing.

Use your own test results, leave out passwords and personal information, and check any confidentiality or disclosure terms you agreed to. I’d also contact the vendor so they have a chance to fix the thing. That doesn’t mean they automatically get to veto your post because they’d rather nobody heard about it.

Publishing your tools can raise separate questions. In particular, a DMCA exemption that lets you do the research doesn’t automatically let you distribute the software you used to bypass access controls. The Copyright Office explains that distinction, and the EFF’s reporting FAQ covers publication risks more broadly. Check these before posting tools or material you’re unsure about.

Good intentions are not permission

You may have heard that the Department of Justice tells prosecutors not to charge good-faith security research under the CFAA. It does, in its charging policy. That means work done solely to test, investigate, or fix a vulnerability, while avoiding harm and using the findings mainly to improve security or safety.

That’s good news, but it’s an instruction to federal prosecutors, not permission from the owner. It doesn’t give you legal immunity or control what other authorities do. It also explicitly excludes extortion, so finding a bug and threatening the owner isn’t covered just because you call yourself a researcher.

Targets you may use in this course

You don’t need to sort out a bug bounty agreement to start this course. We supply targets for the exercises. When choosing something to practice on, look for one of these:

• Course targets: Use the supplied target and follow the boundaries in its lab instructions.
• Systems you own and control: A program running in your local VM is a good place to experiment. Your employer’s production application needs separate approval, even if you wrote part of it.
• Training platforms: Work on the challenge you’ve been assigned under the platform’s rules. Other students’ machines and the site’s login service aren’t included just because you have an account; the login page is not a bonus challenge.
• Explicitly authorized systems: A friend can agree to tests on a spare router they own and control. Their permission doesn’t extend to their ISP or other people’s traffic.

For a bug bounty, find the application in the program’s target list and read the testing and reporting rules. A company having a bounty doesn’t mean everything it owns is included.

Checkpoint

The authorization check

Before testing, make sure you can answer these three questions:

1. Who owns this target?
2. What gives me permission to test it?
3. Does that permission cover the exact action I am about to take?

Missing an answer? Ask whoever can authorize the work before proceeding, and keep their written answer as evidence of what was agreed.

Staying within the agreed scope

If a lab gives you an idea outside its scope, try it in an isolated setup you own and control. That’s one of the nice things about a local test program: you can change it and break it without making it someone else’s problem.

If a test unexpectedly reaches an unapproved system or exposes someone else’s private data, stop. To recover, record only the non-sensitive details needed to explain what happened and report it through the agreed channel. Don’t collect more private data to prove you can collect private data.

Knowledge check

Question 1 of 5

You buy a smart bulb and find that it relies on a vendor cloud service. What does owning the bulb establish?

Permission to test the bulb and every service needed to operate itOwnership of that device, with cloud testing needing separate authorizationPermission to test other bulbs of the same model using your own account

Check answer

Before you test a camera

You buy a used security camera for research. Its app connects to a vendor cloud, and the seller’s account is still linked. You want to investigate the camera and publish your findings.

Before starting, decide where you could test, what falls outside your permission, what you could share, and when you’d stop. Compare your answer with the discussion below.

Check your plan

I’d sort out the seller’s account first. Use the documented reset or transfer process to clear their data and unlink the account, then put the camera on an isolated network you control. If it’s still linked, ask the seller or vendor to fix that before investigating. You bought the camera, not their account.

The seller’s account and the vendor’s cloud are both outside your permission. Keep the tests on your camera and stop if they reach either of those, or any other unapproved system. Your write-up can explain what you found using your own test data, without passwords or private recordings.

If your plan only says “I own the camera,” add what you’ll do about the account and cloud connection before starting.

Once you know what you’re testing and why you have permission, you can concentrate on figuring out how it works.