MyNOG 9: Vulnerability Reporting Program on a Shoestring Budget
0 likes95 views
APNIC developed a vulnerability reporting program (VRP) to provide a point of contact for security researchers to report issues, despite lacking the budget for monetary bounties. The VRP goes live in July 2020, has generated numerous vulnerability reports, and has since partnered with HackerOne for managing and triaging these reports. Lessons learned from the first year highlight the importance of good communication and established procedures for handling vulnerability disclosures.
![The VRP layout (1/5)
• Background of APNIC
– Who we are, what we do
• Introduction of the VRP – “Bug Reporting”
– “We value the hard work of the security research community, and
welcome responsible disclosure of any vulnerabilities in our products
and services.”
– Please use csirt [at] apnic.net
– “We aim to reply to all reports within 7 days, and to resolve reported
P1-P4 vulnerabilities within 90 days”
8](https://image.slidesharecdn.com/trackb-01-jamie-apnic-vulnerabilityreportingprogramonashoestringbudget1663214867-220927133250-2af67a-221007000344-dcbc927b/85/MyNOG-9-Vulnerability-Reporting-Program-on-a-Shoestring-Budget-8-320.jpg)
MyNOG 9: Vulnerability Reporting Program on a Shoestring Budget
- 1. 1 Vulnerability Reporting Program on a Shoestring Budget Insights from the creation and first year of APNIC’s VRP MyNOG 9 19 Sept 2022 Jamie Gillespie, Internet Security Specialist, APNIC
- 2. About APNIC • APNIC is the Regional Internet Registry (RIR) for the 56 economies that makes up the Asia Pacific region – Distributes and manages IP address – Not-for-profit, purposefully open and transparent – Approx 120 staff, mostly in Brisbane Australia – Multiple data centres in Australia and internationally – IaaS hosting on AWS and GCP, multiple SaaS applications/vendors – Not just web sites, but also VPN, SMTP, DNS, FTP, whois, RPKI and even rsync 2
- 3. In the beginning… • APNIC has an internal IT team (actually two of them) – Internal vulnerability scanning – External penetration tests • APNIC also has developers writing new applications • APNIC CSIRT was created internally to formalise incident response procedures, and overall information security work 3
- 4. Early vulnerability reports • Without a proper security point of contact, security researchers would email privacy@ or even hr@ addresses • Occasional scam email would come in too 4
- 5. Conception of the VRP • We should have a point of contact for security researchers • But we’ll need to advertise it somehow • We’ll also need to set some rules • This sounds like a bug bounty program • Hmmm… but we can’t pay out bounties like the big profit driven companies can • Would a bug bounty program without the bounties work? 5
- 6. Conception of the VRP • The APNIC Vulnerability Reporting Program! – aka Vulnerability Disclosure Program / VDP • Reading many other program texts led to a draft VRP • Circulated draft to IT teams for feedback and improvements • Used an early template from disclose.io for Safe Harbor – disclose.io now have entire VDP generators and templates • Got the APNIC Legal Team involved to approve the wording 6
- 7. The VRP layout • Background of APNIC • Introduction of the VRP – “Bug Reporting” • In Scope • Out of Scope • Report Details • Safe Harbor 7
- 8. The VRP layout (1/5) • Background of APNIC – Who we are, what we do • Introduction of the VRP – “Bug Reporting” – “We value the hard work of the security research community, and welcome responsible disclosure of any vulnerabilities in our products and services.” – Please use csirt [at] apnic.net – “We aim to reply to all reports within 7 days, and to resolve reported P1-P4 vulnerabilities within 90 days” 8
- 9. The VRP layout (2/5) • In Scope – *.apnic.net – *.apnic.foundation – *.isif.asia – *.seedalliance.net – *.apidt.org 9
- 10. The VRP layout (3/5) • Out of Scope – 3rd party sites such as Lets Encrypt, Okta, Cloudflare, Zoom, or similar • If you inadvertently find an issue with these sites while testing APNIC, we’d like to hear about it. However, we cannot provide permission to test these third parties. – Destruction of data – DoS/DDoS – Social engineering – Physical security controls 10
- 11. The VRP layout (4/5) • Report Details – Repeated the csirt email address – “We would appreciate it if your report included the following information” • Your contact information, so we can follow up with questions • A description of the issue and its nature • Detailed steps that allow us to reproduce the issue • A brief description of the security impact of the issue – “As a not-for-profit, we can’t pay out major bounties, but we really appreciate your help in safeguarding our systems.” 11
- 12. The VRP layout (5/5) • Safe Harbor – If you conduct vulnerability research that is in scope, and – if you report your findings to us in a timely manner – We will consider this authorised, and – promise not to take legal action against you 12
- 13. Making the VRP accessible • Generated and published a GPG key for encrypted email • Creation of a security.txt file with the help of securitytxt.org 13
- 14. Who is on the receiving end of reports? • The IT teams will receive reports in our ticketing system – csirt@apnic.net already existed, but not publicly used • The IT teams will manage upgrades of 3rd party software • What about the code APNIC creates internally? • THE DEVELOPERS! – Oh hey, developers, we didn’t forget about you (honest) – Can we inject security patching procedures into your development cycle? – Can we impose time frames for confirming vulnerabilities, fixing vulnerabilities, testing, and pushing into production? 14
- 15. A premature birth • Just 5 days before the VRP web page is published, a vulnerability report is sent to csirt@apnic.net – Stored self-XSS (Cross Site Scripting) in a display name field • Early test of our vulnerability report handling procedures • Added a Thank You section to the VRP page, with our early bird security researcher as the first entry. 15 Thanks Denny!
- 16. The (actual) birth of the APNIC VRP! • VRP web page quietly went live on 28/07/2020 – https://www.apnic.net/community/security/apnic-vulnerability-reporting-program/ • APNIC Blog post on 03/08/2020 – https://blog.apnic.net/2020/08/03/apnic-launches-vulnerability-reporting-program/ 16
- 17. A slow controlled start 17 Note: these numbers are based on first reports of unique validated security vulnerabilities 0 2 4 6 8 10 12 14 07/2020 08/2020 09/2020 10/2020 11/2020 12/2020 01/2021 02/2021 03/2021 04/2021 05/2021 06/2021 07/2021 08/2021 09/2021 10/2021 11/2021 12/2021 Number of Vulnerability Reports (monthly)
- 18. 0 10 20 30 40 50 60 70 80 90 07/2020 08/2020 09/2020 10/2020 11/2020 12/2020 01/2021 02/2021 03/2021 04/2021 05/2021 06/2021 07/2021 08/2021 09/2021 10/2021 11/2021 12/2021 Number of Vulnerability Reports (monthly) Number of Reports Cumulative Number of Reports A slow controlled start 18 81
- 19. Types and severities of vulnerabilities • 16 x Information Disclosure • 10 x Reflected XSS • 5 x Denial of Service • 5 x Stored XSS • 4 x Clickjacking • 3 x P1 vulnerabilities – SQL Injection – Sensitive Information Disclosure 19 0 5 10 15 20 25 30 35 40 P1 P2 P3 P4 P5 Vulnerabilities by Severity
- 20. P1 Incident that went public 20
- 21. Types and severities of vulnerabilities • 16 x Information Disclosure • 10 x Reflected XSS • 5 each of: – Denial of Service – Stored XSS • 4 each of: – Clickjacking – CSRF 21 • 1 each of: – Exposed admin panel – Exposed Kibana instance – Host header poisoning – Insecure cookie setting – Insecure Direct Object References – Leaking info via referrer – localhost DNS record can lead to XSS – Missing HSTS – Open redirect – REST API exposed – Subdomain takeover – Unrestricted file upload – Unsafe Cross-Origin Resource Sharing – Weak password policy • 3 each of: – Bypass business logic – Email flood - lack of rate limiting – WP xmlrpc.php exposed • 2 each of: – Cached data access after logout – Conject injection – Cookie stealing – Missing SPF – No expire after pw change – Sensitive information disclosure – SQL injection
- 22. Who reported the vulnerabilities • 45 security researchers sent in single reports • 9 security researchers sent in two reports each • 3 security researchers sent in three reports each • 1 security researcher sent in four reports • 1 security researcher sent in five reports • Most multiple reports came in on the same day – Half for the same service, half for different services • We also received 33 duplicate reports – Mostly relating to original reports received in the first 4 months 22 Note: these numbers are based on first reports of unique validated security vulnerabilities
- 23. Lessons learned • VRPs / VDPs are useful to complement existing security tools and practices • Good communication with internal stakeholders is important – Before, during, and after launch • Standard operating procedures and response templates ensure consistent handling of reports and reporters • Bounties aren’t required to launch a VRP • Management reporting gets harder with more reports and details 23
- 24. What’s happened since? • At around the one year mark of operations, APNIC compared the services of vulnerability coordination vendors • HackerOne was selected to receive, validate, and triage vulnerability reports for APNIC – They also provide reporting and privately advertise to their researchers • Triaged reports are sent to our IT team who then route the report to the appropriate product development team 24
- 25. What’s happened since? • The VRP web page has been updated to include the HackerOne submission form, in preference to csirt@ • The Out of Scope list has been expanded – “Working as intended” items such as FTP directory listing – Rate limiting issues on non-authenticated endpoints – Missing security flags on cookies that don’t relate to authentication • The Thank You / Hall of Fame list has grown • APNIC is more secure 25