Hi. I'm blue linden, and I'm in high school.
If you're reading this, I've been probing a service that you either maintain or use a lot as part of your career. Basically, I've hacked and/or reverse-engineered something.
I have a set of guidelines that I follow while doing so, in order to keep myself and everyone involved out of legal trouble, as well as to ensure the product or service I'm exploring has no service disruptions.
This is a non-exhaustive list in no particular order.
From here on out:
- the product or service I'm probing will be referred to as the Product.
- the provider of said product or service will be referred to as the Vendor
- the vulnerability or breach being probed will be referred to as the Issue
- any devices, servers or applications susceptible to the issue will be referred to as Targets
- the process of discovering and reporting Issues to the Vendor will be referred to as the Investigation.
Rule 1: external disclosure
I do not give to or reveal to anyone not directly involved with the Investigation:
- the means to attack or probe the Product
- specific information about the Issue beyond the fact that an unidentified issue indeed exists in the Product
- any tooling used in discovery of the Issue
until 90 days have passed since the Issue has been resolved on at least 95% of Targets, as long as the Vendor is cooperating and has issued a fix.
Rule 2: disruption of services
I make a best effort to avoid disrupting the services or operations of the Product. If I believe I have accidentally broken something, I will come forward as soon as I can and cooperate to fix the issue.
If I believe an action I need to take to find out more would be disruptive, I will not attempt the action and instead come forward, stating that the Investigation is unfinished but that there is potential.
Rule 3: choice of Product
I do not claim to be some sort of Robin Hood who investigates something because it happens to exist. I investigate anything that appears vulnerable at first glance. If I am unable to decompile a binary or ECMAscript-like format into readable code, or if I am unable to use a network proxy to examine traffic, I will likely give up and abandon the project unless I am able to extract information in some other way.
I do not go after anything that I don't believe is worth my time. Unless I am paid, there is no guarantee that I will inspect any Product in particular.
Rule 4: private network access
I will not attempt to gain access to any sort of network or resource that is not:
- publicly reachable via the internet
- mentioned by string in the Product's codebase or in an API response
Examples that are in-scope according to this rule are:
- Public object storage (AWS S3, etc.)
- Private object storage with authentication details embedded in a Target's code
Examples that are not in-scope:
- Internal/corporate networks
- Object storage that sits behind an API proxy
Rule 5: decompilation
Rule 6: testing on friends
Sometimes I need to test something on a colleague's computer or account to prove reproducibility. As such, I will ask them for explicit permission to test on them and describe what I need to do, and only start doing it when they explicitly say yes. If they are ambiguous, I will ask for a clearer answer. I try to keep the number of people I ask this of to a minimum.
Rule 7: timelines
I'm busy. From initial start of Investigation to reporting, I can take anywhere from one week to three months. It depends on the perceived severity and how much free time I have.
Rule 8: Drop Everything And Report bugs
DEAR moments are moments when I find something so bad that I audibly gasp and swear.
These include authentication bypasses, and successful access of someone else's data (with their consent).
I generally report things when I have the time to, outside of school and after other responsibilities, unless I'm being paid to do otherwise. When I find a DEAR bug, I will report that specific vulnerability as soon as possible to the proper people, and request a debrief to an intermediate party by the next morning, such as the Fairfax County Public Schools Office of Cybersecurity.
Rule 9: CVE
As of 2024-02-05, I will request a CVE ID for every Issue found in a Product, unless there is good reason not to.
Rule 10: environmental security
The Investigation is almost entirely conducted on hardware I own. Besides Visual Studio Code, no proprietary software is used in the investigation.
My laptop's configuration is available on GitHub. I use tools such as AppArmor to keep basic viruses from assuming control over the system. My main system disk is encrypted with a strong password.
I do not leave my computer unlocked while I am away from it, and all of my passwords are either over 25 characters or randomly generated and over 20 characters.
Rule 11: payment
If I am looking for Issues for the good of my community or school district, payment is not necessary.
I will not hold any already collected information for ransom. If I want payment from the Vendor, I will clearly say so and hold off Investigation until it is confirmed I will be paid. If I am denied payment, I will either abandon the Investigation or do it for free under my normal rules.
I may request some amount of payment after the Issue has been disclosed to the Vendor and resolved on a majority of Targets. Payment in this case is completely optional.
My publication of the Issue to the open internet is not contingent on whether I receive compensation or not. Unless I directly signed an agreement stipulating that I cannot publish details to the website, I have every right to do so (responsibly, see rule #1) as is standard practice in the cybersecurity industry.
I will not sign an agreement unless I am compensated for it.
My general "fair" rate is $45 per Issue, if the Issue is basic and trivial to find. The more serious the Issue is, the more I'll ask for. This could be around $500 per Issue for things like remote code execution or SQL injection.
Keep in mind that payment is almost entirely optional, and that the above section defines how I'll be asking for payment and how much I will request.
Rule 12: the blog
I run a blog on this website. After my external disclosure requirements from above are met, I am able to talk about the Issue and publicly provide technical details, including detailed reproduction steps and code snippets I have created.
I will likely post about the Issue on my blog, under a funny title and in my standard informal writing style. Vendors cannot control the content of this blog post beyond defining no-go topics. I will also mention whether the Vendor was cooperative or not. If I have been paid by the Vendor in any way, I will mention it in my post and other communications.
Rule 13: bug bounties
All of the above rules are overridden if I am paid by a Vendor to Investigate their Product, or if I am participating in a public Bug Bounty program.
- blue linden