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 85% of Targets, or 120 days since disclosure, as long as the Vendor is cooperating. I am willing to work with the Vendor on this timeline.
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 with the Vendor 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 or I am under legally binding contract, 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
My main experience is with JavaScript code. As such, I use a tool called Webcrack for the majority of my deobfuscation and decompilation of JavaScript. This is a local tool that runs on my hardened personal computer.
If source maps are provided as part of a JavaScript bundle, they will be used as well.
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: 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 12: programs
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 or private Bug Bounty or Responsible Disclosure program.
- blue linden