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

Keynote - How Do You Actually Find Bugs?
http://usmacd.com/cn/How_do_you_actually_find_bugs/
Author
henices
Posted on
September 6, 2023
Licensed under