7 Steps to Avoid Uncoordinated Vulnerability Disclosure
Imagine the following situation. You work as a security manager for a company that owns the website www.example.com. One day, your sales department receives an email from an unknown individual. The sales department forwards it to you. The email has the following content:
You example.com/login.php page break. Send XSS.
</script><img/*%00/src="worksinchrome:prompt(1)"/%00*/onerror=’eval(src)’><img/
src=`~` onerror=prompt(1)><form><iframe
src="javascript:alert(1)"
;>If no fix, I send to FD in month.
Here’s a list of steps that describes how you should react to such a message to avoid public uncoordinated vulnerability disclosure.
Step 1. Assess and Fix Your Attitude
First of all, realize that you have not been hacked. If this were an attacker, the potential impact would be much greater. Your web page could have been used to attack somebody else or you might have a lawsuit from one of your customers because their sensitive information was released into the wild.
The person who contacted you is an independent security researcher. They find security issues and report them in good faith, making money from bug bounties.
Do’s:
- Have respect for the hacker. They contacted you to help, not to harm you.
- Be patient. They might not be an efficient communicator.
- They might not be native English speakers. Try to find out what’s their preferred language and find someone who can help you with translation.
- Respect their privacy. If they use a nickname and/or an anonymous proxy, do not push them into revealing personal information. If they use PGP to encrypt and sign their messages, use their public key to encrypt your responses as well. Privacy is important for hackers because not all businesses are as smart as you and many of them take legal action against non-malicious hackers, often involving law enforcement.
- If you fail to follow the described process and the hacker discloses the vulnerability publicly, realize that it’s your own fault, not the hacker’s.
Don’ts:
- Don’t ignore the message. If you do, the bug will most probably be made public before you fix it.
- Don’t try to cut corners or you may be shamed in the hacker community. As a result, other hackers will not help you in the future.
Step 2. Communicate Efficiently
To avoid public disclosure of your security vulnerabilities, make sure that the hacker is kept up to date on the bug. They want it fixed as soon as possible because other parties might be endangered. For example, a Cross-site Scripting (XSS) vulnerability in your web application may be used to attack other people using your domain name to build false trust via social engineering.
Do’s:
- Delegate responsibility. The original email might have reached a non-technical person, for example, your marketing contact address. Select a technical employee, preferably from your IT security team if you have one, and make them responsible for further communication with the hacker. Make sure that the selected representative follows the guidelines in Step 1 above.
- Ensure that your employees know how to escalate potential security issues and do not ignore such reports. Advice employees in public-facing roles on how to handle security reports – who to forward them to and whether to bypass the escalation process used for regular inquiries.
- Write openly and often. Keep the hacker updated. Contact them immediately to confirm that you received the report and are looking into it. Give them time estimates, for example, that you intend to finish research in a week. Keep them updated with the state of fixing.
- Non-malicious hackers follow responsible disclosure practices. They usually give you a specific timeframe to fix the vulnerability before they disclose it publicly. If they have not specified that timeframe, ask them about their preference and negotiate the timeframe if necessary.
Don’ts:
- Don’t be afraid to ask for additional help or information. If you have a problem with confirming the vulnerability, ask the hacker. If you have a problem fixing the vulnerability, it won’t hurt to ask the hacker for tips.
- Don’t keep the hacker waiting. If you promised that you will look into the matter within 7 days and you did not, make sure to update the hacker, apologize, and provide a new time estimate.
Step 3. Confirm the Vulnerability
You should confirm the reported vulnerability and learn more about it. This will make the bug easier to fix.
Do’s:
- Use an automated web vulnerability scanner such as Acunetix. If you use Acunetix with AcuSensor, it will provide additional information about where the error is located in the byte code or source code. With Acunetix, you can also scan for both web and network vulnerabilities.
- If the scanner is not able to find the vulnerability or if you require more information, you may need to delegate an IT security team member to perform vulnerability analysis or hire an external company to perform one for you.
Don’ts:
- Don’t assume that the vulnerability does not exist if your software or your team cannot confirm it. Ask the hacker for help. If the hacker did not provide a proof-of-concept, ask for one. If they did, ask for more details.
Step 4. Remediate Promptly
Even if the reported vulnerability is not very dangerous, you should treat it with priority because it has been reported by an external source.
Do’s:
- In many cases, you can use a temporary workaround such as a web application firewall (WAF) rule to protect your system until you can fix the vulnerability. If you confirmed the vulnerability using Acunetix, you can automatically export such a rule.
- If the vulnerability was found in code that has been developed in-house, take this opportunity to educate your developers about how to avoid such vulnerabilities in the future. The Acunetix blog has dozens of articles about web vulnerabilities and methods to avoid them.
- Ask the hacker who reported the issue to confirm the fix.
Don’ts:
- Don’t think that a vulnerability in third-party software is not your problem. If the third-party does not provide a fix, you may have to either push the manufacturer or create your own temporary solution (for example, in the case of open-source software). Zero-day vulnerabilities in popular third-party software are often the most dangerous because black-hat hackers try to exploit them first.
- Don’t treat temporary measures as permanent fixes. A WAF rule will just make the problem disappear until someone finds a way to approach it from a different angle.
Step 5. Remunerate the Hacker
Even if you do not have a bounty program, you should appreciate the help from the hacker. Their report saved you from a potentially damaging situation. The bug might have been the target of active exploitation causing a data breach or reputation loss.
Do’s:
- Decide internally what you are willing to pay the hacker for their help (and then see step 7 below). Make sure that those responsible for financial decisions are aware of potential losses if the vulnerability was found by a malicious hacker instead.
- Be ready to increase remuneration if the hacker helps with further remediation and retesting.
Don’ts:
- Don’t try to get out of paying. Don’t ever lie that someone else reported the bug earlier and already got the bounty. Such an approach is highly unethical and harmful to the independent security researcher community.
Step 6. Disclose the Vulnerability
Once the vulnerability is fixed, you should admit to it, for two reasons. First of all, it might have been silently exploited by a black-hat hacker and you don’t want to find information about it in third-party sources earlier. Second of all, a public report from you will have a very positive impact on how your company is perceived by the security industry. For example, see what Cloudflare did when they encountered a major problem.
Do’s:
- Prepare a detailed report including information about the person who found the vulnerability, how it was confirmed, and how it was fixed. Include as many technical details as possible.
- Publish the report on your web page, for example as part of your blog, and/or on social media. If necessary, communicate directly with all parties that might have been affected by the vulnerability.
Don’ts:
- Don’t be ashamed of the vulnerability and don’t keep it hidden. Everybody makes mistakes, it’s how you fix them that matters.
Step 7. Build a Vulnerability Disclosure Policy
Learn from this experience. A lot of steps above probably had to be done ad-hoc and you should be prepared for similar situations for the future. The best way to do it is to create your own vulnerability disclosure program and a bug bounty program.
While a lot of companies don’t have such programs, the biggest players in the world such as Google are well-prepared. Follow in their footsteps.
Do’s:
- Describe your preferred vulnerability disclosure process. Decide how you would like to be informed about vulnerabilities in the future. Delegate a person to receive reports via email, phone, or any other channels that you select.
- Create a security.txt file for your website with relevant information and make sure that contact information is easy to find.
- Decide the scope of bug bounties that you are willing to pay. Provide payout ranges and conditions such as business criticality and vulnerability types. You may use Acunetix vulnerability assessment to decide which vulnerability types should be worth more.
- Publish information about your vulnerability disclosure process and bug bounty conditions publicly on your website. Make it easy to find and easy to read even for those who don’t speak English well.
- You can also select a third-party partner to help you with vulnerability reports, for example, HackerOne and Bugcrowd. Such partners automate a lot of steps involved in reporting vulnerabilities and paying bounties. They are also considered a safe harbor by the community and help hackers avoid unethical businesses.
Don’ts:
- Don’t think that a vulnerability disclosure policy will solve all your security issues. Continuously perform your own vulnerability research. For example, make sure that you use a vulnerability scanner, preferably in an automated manner, either based on schedules or as part of your SDLC.
