Keynote - How Do You Actually Find Bugs?

https://www.youtube.com/watch?v=7Ysy6iA2sqA&ab_channel=OffensiveCon

• Temperament
  • Curiosity
  • Detail-oriented
  • Ability to deal with failure and continual evidence that you’re wrong
• Learn how to deal with failure
  • Two projects (can be unrealeted, or different parts of the same)
    • Learn to recognize whe you have hit a wall and have become unproductive
    • Switch to your secondary project
  • Consider having a development project as your seconary project
    • Do an achiveable, measurable task
    • Regain a sense of achievement
• Moving on - Knowning when to quit
  • You will return it in the future
• Motivation - Remaining Enager
  • The more you’re curious about how a technology works or how an algorithm achives its goal, the less monotonous code review is
• Motivation - bug patching
  • bugs being patched is frustrating
    • … but they are evidence that you were on the right track!
• Confidence
  • Research is a daunting filed to enter
  • Some security reseacher you respect had the same self-doubt coming in, and have recurrences from time to time
  • Growth mindset: “I can’t do that … Yet”
• Bias and assumptions
  • Common code reviewer biases
    • Everyone has looked at the already (many eyes make all bugs shallow)
    • Even if I found something, it will be unexploitable (Server side)
    • The X attack surface is not interesting now (eg, media parsing in browsers)
    • There are no more bugs in this
    • The protocol doesn’t allow you to do X
• Auditing Process
  • Understanding the code
  • Documenting your findings
  • Identifying bias
  • Tooling
  • Revisit the code base
  • Analyze failures
• Attampt to understand the code
  • A lot of people try to short-circuit this process
    • Reliance on tools
    • Fuzzers/static analyzers are a guide, not the whole process
  • Many of today’s vulnerabilities are complex, and require in-depth understanding of the codebase
  • The more you understand about how the program works, the better equipped you are to find bugs ( and exploit them)
  • The best way to understand how something works is to explain to someone else
• What I’m looking for
  • software risk = available attack surface * complexity
  • attack surface can be indirect
    • even mitigations are attack surface
  • often you initial perception of attack surface is naive
    • Hidden/non-obvious attack surfaces are the best
  • Complexity is plentiful
    • Feature driven (thanks w3c)
    • Legacy support
    • Often avoidable: the anomaly of cheap complexity
• Borrwoing ideas
  • Bugtracker / Diffs
    • Can show where a bug is
    • Can inspire new ideas: variants, same bugs in other codebase
    • Mean but viable: track commits by error-prone developers
  • Comments in the codebase
    • Descripbe things I’d never thought of
• Document your findings
  • Get into the habit of documenting
    • ideas, bugs candidates, idiosyncrasies, data structure, algorithms
  • Documenting failed ideas is as important as documenting successful ones
    • avoids repeating thie idea sometime later
  • Long term view: I’m going to revisit this later
• Revisit code bases and failed bugs
  • code bases are not static
    • coee rewritten
    • Features added/changed
  • Environment is not static
• Analyze your failures
  • if someone succeeds where you didn’t, have a look at what they found
  • Try to figure out: why did I miss it?
  • Is this a one-off or teachable trick/blind spot
  • Can you improve on that?
  • Is there a pattern in those falures?
  • Failures is an oppotunity to learn