Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WTD Bay Area Presentation: What Not to Document & Why

97 views

Published on

Our top priority while writing documentation is helping our users—as it should be. If you document some things too thoroughly, though, you may also help people you don’t want to assist. Attackers looking to exploit your software and harm your users are also reading the docs. This year, one company ran into this problem when a prominent security professional posted a documentation snippet to Twitter—accidentally revealing a vulnerability that launched the security team into an emergency response plan. In this talk, I’ll explain how you can support your company’s security posture by strategically omitting information that helps attackers more than end users, what information is most important to exclude, and how each piece of information can help an attacker if you choose to include it.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

WTD Bay Area Presentation: What Not to Document & Why

  1. 1. WHAT NOT TO DOCUMENT AND WHY Margaret Fero
  2. 2. WHOAMI
  3. 3. TABLE OF CONTENTS • Case Study: The 0Day Docs Caused • What Not To Document: Specifics • URLs used in authorization • Default Keys • Password Requirements • Any setting you don’t recommend • How Can I Tell Not To Document Something?
  4. 4. CASE STUDY ATLASSIAN’S DOC-INITIATED 0DAY
  5. 5. WHY A CASE STUDY?
  6. 6. QUICK TERMINOLOGY OVERVIEW ATTACKER Someone who wants to use your system to cause harm (or pretend they do, in the case of a testing team) VULNERABILITY A way that an attacker could cause harm 0DAY A vulnerability publicized without advance warning to the development team, named for the 0 days of notice to patch
  7. 7. IN LATE 2019, A SECURITY RESEARCHER GOT STUCK… • @SwiftOnSecurity is a security researcher known for their work and their memes. • They were reviewing unusual DNS lookups within their organization’s network, and were suspicious of one. • They checked the docs.
  8. 8. WHAT’S THE BIG DEAL?
  9. 9. WITHIN AN HOUR, ANOTHER RESEARCHER RESPONDED
  10. 10. CVE-2019-15006 (CVSS 6.5) AFFECTED Everyone who used the Confluence Previews plugin in Confluence Server or Confluence Data Center POTENTIAL IMPACT An attacker could see files that were edited, edit files, and possibly access user information TIME TO PATCH 0 days
  11. 11. WHAT WENT WRONG HERE? SOFTWARE Developers didn’t catch that the code was insecure before pushing to production, and/or accepted a risk that probably should not have been accepted DOCUMENTATION Explained the functionality and behavior of the product very thoroughly, but perhaps a little too thoroughly RESEARCHERS Admittedly posted while work was in progress, accidentally causing a scramble to patch (and becoming ineligible to collect a reward for reporting)
  12. 12. WHAT NOT TO DOCUMENT SPECIFIC EXAMPLES
  13. 13. URLS USED IN AUTHORIZATION USERS GET • A URL to safelist • A better understanding of how your authentication flow works ATTACKERS GET • A high-value target point
  14. 14. DEFAULT KEYS USERS GET • The key they need to set up, and change it if desired ATTACKERS GET • The key that almost-every user is definitely still using
  15. 15. PASSWORD REQUIREMENTS USERS GET • A clear outline of what criteria their password must meet ATTACKERS GET • Exact regex criteria for faster, easier bruteforcing and other password attacks
  16. 16. ANY SETTING YOU DON’T RECOMMEND USERS GET • Curious about what it does and whether they can use it ATTACKERS GET • A strong hint that you can cause unexpected behavior by playing with this now- shiny new toy
  17. 17. HOW TO TELL WHAT NOT TO DOCUMENT SIGNS AND SIGNALS
  18. 18. NOT RECOMMEND ED
  19. 19. INSIDER INFO
  20. 20. CONCEPTS YOU DON’T FULLY UNDERSTAND
  21. 21. THANK YOU! Write The Docs Slack @maggie Twitter @MaggieFero LinkedIn Margaret Fero

×