[Music]
all right GM welcome back so uh
hopefully all of us are here for the
workshop this
morning this is going to be about
finding bugs
which is really what security is all
about finding and fixing bugs
hopefully and uh this is an interesting
format for a workshop we trying this out
um recently so this is going to have 42
tips from the four security researchers
that you see
here 42 why 42 42 is supposedly the
ultimate answer to all questions in the
Galaxy so why not finding bugs as
well and the for security researchers
here I'll let my smarter colleagues
introduce themselves first with
uran thank you um I am a security
researcher at consensus diligence where
I work mostly on tooling and automation
so you might have used a couple of my
tools uh but I am also a buck Bounty
Hunter so most of my tips today will uh
go into that part of security research
hi everyone I'm dcho um I work for the
red y I'm a co-founder we do security
for the public benefit of ethereum
ecosystem um and in the past I used to
be a l aitor open sing for many years
and before that I was a web developer
and
pester hey everyone I'm Nat I'm an
independent security researcher um I
spent four years at Cher La bits uh
where I did mainly Security reviews and
before that was blockchain developer for
three years so yeah today my tips are
kind of going to be blockchain Dev
related and security researcher
related fantastic and I'm uh Rajiv so
I've been a security researcher pretty
much my whole life started with ethereum
security roughly about U 6 to8 years ago
um early participant in some of the
leading on audit contest
platforms um and then uh for the last
couple of years I've been a lead
security researcher with speit Cantina
um and in this context um started secum
about three years ago so secum was um
was was funded by an ethereum Foundation
Grant and collaborating with some of the
leading projects in the space the goal
was really to scale ethereum security
right and by that we mean onboarding the
next hundreds and thousands of security
Auditors U to make ethereum safer so
secum is um is really an online
community known for its boot camp check
it out online has monthly quizzes
designed by uh many of the well all all
the people standing here and many many
others in the room as well uh check that
out and U secum also hosts trustex which
is uh one of the leading ethereum
security focused events so with that we
will kick it off right the first
question we really need need to ask is
why right why why are we doing this
Workshop why are we trying to find bugs
and as you can see the whole not not
just smart contracts or opsc and other
things right the whole domain of
blockchains right is really about trust
and in this
case finding and fixing bugs is really
one of the biggest um you know technical
risks not just in the base layer in the
layer ones and the layer twos in the
bridges and anything else in between but
also in all the daps right all the smart
contracts that really uh and and all the
glue that holds them together right we
need to be finding and fixing
bugs why so why is that important I mean
it should be very obvious to many of the
folks many of the security researchers
here but just to sort of put it once
more if we would like ethereum to be the
world computer if we want to really
onboard millions and billions of people
onto the onchain economy and if you
really want eth to be ultrasound money
we need to make it Ultra safe right so
that's really the goal here so with that
um context will'll kick it
off and and this this really sort of
hopefully justifies it right I mean this
is from defi Lama as you can see and I
don't I mean this is probably
representative it really does not
capture all the other uh fishing and
many of the other things that uh are
draining millions and billions so this
is getting better I mean this graph sort
of gives us a warm fuzzy feeling that
hey we may be getting better but I think
we really have a you know long long path
ahead so with that we'll start with the
tips thank you
clicker awesome so all of you are
probably on Twitter uh if you're not
you're quite unique and if you've been
on Twitter and read any of the posts
around bounty hunting security research
uh you see a lot of grind set Focus post
and um I'm not saying hard work and
dedication isn't what's going like
required to be a good security
researcher but I honestly believe that
going into security research with the
mindset of ah I need to grind so hard
work 16 hours a day is the worst
possible approach um if you look at
other Industries like doctors um that
have a similar kind of mindset where
it's like oh I'm going to work so many
shifts uh I work so hard if you look at
the amount of incidents that are caused
by people working multiple shifts it's
insane uh and the same thing happens for
security research like I'll be stuck on
a problem for four hours at the end of
the day and the next morning I'll solve
it in 5 minutes like staying stuck on a
problem just because you feel like you
need to work hard not a good
approach okay tip two scoping out
targets and not just picking anyone at
random is a pretty good idea when you're
doing bounty hunting there's so many
programs and if you just pick one at
random well it can be a fun approach but
it's probably not that efficient so
probably the primary thing you should
FOC focus on is the amount of time that
you have available closer okay uh
probably what you need to focus on is
the amount of time that you have
available on these targets so uh maybe
don't go for like a bridge
implementation or uh like a an L2 if you
just have a weekend um and of course
like if you're looking to make a living
out of this or a significant amount of
money then don't go for projects that
offer low bounties one thing I actually
look at a lot is not necessarily the
height of the main Bounty which is like
10 million or one million it's usually
very high I look at the the the Bounty
that's offered for the high
vulnerability because that's usually a
really good signal about how much a
project actually cares about security if
they won't offer anything for highs or
if their high is like 10K and their crit
is 10 million um this is just like
random
um that's not a good sign that they
actually care about security uh they
just wna yeah prevent the main
things okay tip three try to sleep sort
up okay so this one actually happened to
me uh I was trying to sleep uh and then
well as as it happens my brain is like
oh you were working on this problem
here's the solution and so there was
like in the middle of the night typing
up a bug report
um the idea here is not to try to work
well you're trying to sleep it's more so
um exploiting the idea that you have
like your brain is doing passive
processing on in while you're doing
random things like trying to sleep or
doing the dishes um and to really
leverage that it's important to not try
to do too many things at the same time
because so for example if you're bounty
hunting on a project don't switch to a
different project just keep doing this
one go for a walk let it process and
find some bugs um and don't go like
watch Netflix and fill your head with
different things because then you can't
like
Leverage this ability of your brain like
um I have a cool example from when I was
in university um was working really hard
on a problem uh like the we had these
days where you had to solve a a
challenge in a day uh kind of hackathon
um and it was like super stuck for like
the first four hours of the day um took
a walk to get lunch passive processing
happened solved the issue like right
after lunch so yeah till the year take
some breaks uh and leverage this passive
processing okay now some tips about how
to approach bug Bounty
discussions if you're doing Buck
bounties eventually you'll have a
discussion with someone because projects
don't always agree with the impact or
what you found um Everybody responds
differently uh there can be some
emotions involved when you tell someone
their code is broken um so one of the
things that's really useful is basically
learning a little bit of rhetorics and
preparing for fallacies um people will
come up with arguments that don't work
addressing them or strategies that
basically derail a discussion being
prepared for them will just make your
life easier in the
end another tip on Buck Bounty
discussions is kind of taking the
mindset of working with this project as
a business partner that you might want
to do an audit with uh later um this
greatest s communication that's that's
much more productive and much less
likely to result in a situation where
you're just name calling like no your
code is and then they're saying no
you can't find bugs and everything sucks
um so this really uh helps things out
there and as an at a benefit if you
actually do end up buiness being
business marter laser uh you have a much
much better
relationship okay then um it's going to
be super useful if you diversify your
skill your skills so with defi there's
all these super useful uh resources like
secur uh um that can help you become
like a security researcher uh but it's
often easy to overlook the fact that
learning other things that aren't
necessarily directly related to um defi
or smart contract security is going to
be incredibly useful like learning
quantitative Finance is
has been super helpful for me like
there's a couple topics here uh like for
example learning how compilers work I
think is an insane thing like insanely
useful thing to know because you'll be
so much more familiar with how
programming languages work how solidity
Works under the hood you just get an
intuitive sense of how these things work
and that in the end will help you
understand code better find and find
more bugs um it's also
just something that keeps things
interesting you know like after a while
maybe defi gets a little bit boring this
kind of switches it up uh so it's it's
also just something uh to have some
fun
okay now some strategies that you can
actually
apply uh in uh your buck hunting
process I think I think one of the
things that works really well is uh
finding a paradigm and specializing in
it so for example in defi uh you have
systems that provide leverage so what
you can do is become super familiar with
all the things that you need to do to
implement leverage systems and what can
go wrong once you know all these things
you can just quickly go into all the
programs that have some type of Leverage
see if they do everything everything
right and if they do you just move on to
the next project so this is kind of like
a an approach where you go super broad
um and it can be super efficient what's
important here is to get pick a paradigm
that is relatively unknown or that you
think nobody else is specializing in
because that way you have some
competitive Advantage um I um so uh I
guess leverage and concentrated
liquidity are a little bit old now uh
but I guess like various CK topics uh
can be something right now that there's
not that many security researchers that
specialize in these where uh there might
be uh some some good opportunities um
and I just pick something that you find
interesting to be honest uh because
that's the best way uh to to learn and
go about this
all that was the go broad strategy now
for the go deep strategy um
instead of just going for a bunch of
projects for one topic you can pick one
project and then go deep on that one
um this is an approach I usually take
because I have like I'm very time
constrained I do like weekends like
short weeks um and the approach I
basically take is I I pick a project and
then I take some time to explore it and
identify by all the like the interesting
bits the risky bits uh the parts that I
think are going to be super difficult to
implement right if I were to implement
them that myself and then I basically
just go have a look at those um and see
if they if they actually made the
mistakes that I think uh they would have
um and that's actually like a super time
efficient uh approach when you when you
think about it uh and this kind of
exploits the fact that as a bounty
hunter you're not an auditor as a bounty
hunter you don't care about finding all
the bugs it doesn't matter like it
doesn't matter if something is left
after you go by as an aitor that kind of
sucks if that happens but as a bounty
hunter we just want to find a bug as
soon as possible and this approach will
allow us to do that we we'll just have
to look at like the critical code the
code that does liquidations uh we don't
have to look at all the like boring bits
like usually you don't look at like the
erc20 contracts where they do all the
interfacing right I mean you could but
that's not the the go deep
approach tip nine read the documentation
okay so design mistakes can be critical
people come up with interesting ideas
that fundamentally don't work or are
super hard to do right and from reading
the documentation uh this has happened
to me this has happened to other people
uh you can already notice some bugs and
then you just have to go into code into
the code to
see whether like the bug you think is
there is going to be actually there
quick side note there documentation
usually out of date
uh fortunately unfortunately depends on
how you look at it um and uh there just
like there's going to be cases where you
find a bug in the design a bug that's
been there but they already like came up
with something that prevented it and
just didn't document it at
all even if you don't find anything
reading the documentation will set you
up for a success because you'll have a
good General understanding of what the
code is doing um which is like the best
foundation to actually get started so if
you like when I do
the go deep approach actually the
explore phase for me is reading the
documentation first um because with this
documentation in mind like actually
starting to read the code is going to be
super it's more going to be more
productive because you have some some
contextual awareness of where everything
fits in the in the big
picture
then for my final tip uh this is kind of
a mental model I started applying myself
is when you are reading through a code
base you usually notice like a these
tricks or gadgets where
um it's not really a vulnerability per
se like even if you would submit it it
might be an information or LW but it's
these tricks that allow you to do things
in a system that are odd or usually not
supposed to happen and even though these
tricks are kind of useless on their own
they are used usually involved in um
what you would call a killchain so
critical vulnerabilities generally
aren't critical vulnerabilities not
single bugs but they are kill chains and
kill chains are basically a sequence of
stabs or sequence of bugs that you
string together to achieve a critical
impact and
by keeping track of these little tricks
you find while reading the code base you
set yourself up for success say when you
find an actual bug that's maybe not
exploitable or easily exploitable
directly but when you apply your tricks
it suddenly becomes like a super easy
crit um and just making a list or
keeping a list on a piece of paper or
whatever note taking app you prefer
Apple notes could be whatever uh just
keeping like a bullet pointed list hey I
can trick the system into doing this uh
it's not a security risk but it might be
helpful that's going to set you up for
success in building these skill chains
and basically escalating a vulnerability
from maybe medium or high to a critical
with a lot of impact all right with that
I'll give it over
to
[Applause]
mat all right just a raise of hands how
many of you here are
developers okay a good chunk um all
right so my next few tips um as I
mentioned before I'm going to kind of
split between um developer based and
security researcher based just because
um I guess I've been a developer for
almost as long as I was a as I am a
security researcher um and it kind of
ties into even my current roles
all right so tip one is um architect
first code later um there's nothing
worse than a as a security researcher or
a developer than trying to fix your bugs
and then realizing that one bug fix
results in something else happening
which means you can't fix it anymore and
you have to Band-Aid patch another thing
and then that thing can't be fixed
because you have to Band-Aid patch
another thing um as a security res
researcher that nothing is more
dangerous than this but also as a
developer it becomes really hard to
manipulate your code to add new features
um to add behavior um when you have new
code that you want to add um and at the
end of the day it makes your code much
harder to read um that means when you
bring new developers on board um that's
more time it takes for a developer to
understand your system um and more time
for security researchers in a review or
in a bug bount teach to understand what
you're trying to do um I think this is
probably um one of the most uh
underrated techniques is just to really
think about your code um figure out how
do you what what do you want your system
to do um how do you want to build it um
identify you know the architecture of
your contracts of of whatever your um
system is supposed to do um and code it
later and I know that's hard because
even I tend to sit at a computer and
just write code um but I will say for a
project that go under goes continuous
development and continuous features um
following this kind of practice makes um
just reading that code much
easier this is kind of related to maybe
one of the previous tips um document
everything I think from a security
researcher point of view there's so many
issues that we try to uh find in code
bases and they're because they're either
wrong assumptions or invariants that
maybe aren't correct um yeah sure the
documentation might not accurately
reflect what the contract or the co code
is supposed to do um but as a developer
putting the actual um effort into uh
like documenting what you want your
system to do um how certain functions
work what the expectations are um that
can do a lot to actually helping um
other people understand your code I
think there's also been a lot of times
looking at certain functions um certain
code bases and then realizing that
everything all the documentation doesn't
actually match the implementation and
then for security research is we have to
spend a lot of time trying to figure out
all right if that documentation or if
that line is n correct what is it
actually doing um it can help save a lot
of time um in order to bring people on
board as
well all right this one I'm I'm sorry
for all your develop you developers but
simultaneously test and code um yeah I
know tests aren't that fun to write and
I've been in that space I've been in
that mindset um but I will say that it
does help you think about your
invariance it does think help you or
forces you to think about how you want
your system to work um and it forces you
to like actually test the outputs of
your function which you wouldn't be
doing if you were just writing the
function um you wouldn't necessarily be
thinking about um how a function is
supposed to behave um if you weren't
actually writing the test with it this
can help with at the very least
extending your unit tests extending your
test cases um such that sure maybe your
test your test coverage may not be 100%
but it will be higher than if you were
coding and then testing
afterwards it also helps to use this
method to test for edge cases um because
if you're forcing yourself to say like
there's like a function with an if
statement that covers like different
Corner
cases having a test for that means that
you're also increasing your coverage
there and I think there's kind of a a
really useful use case for these unit
tests is essentially finding bugs before
your Security review or finding bugs
before your bug
Bounty all right um this one is uh kind
of related to what I'm saying before is
trying to automate as much as you can um
there's going to be a lot of bugs when
you write your code that that's already
a known Factor um the more time that you
put in your development process to um
documenting to testing um the more bugs
you'll find when like your code is going
undergoing development and also the
easier it is generally to actually fix
those issues such that hopefully when
you get to your Security review or your
future security practices um hopefully
there's less loow hanging fruit so that
the security researchers can actually
focus on the really fun
technical um architectural maybe even
like protocol level um design concerns
rather than we found another re-entrancy
here um explodable here with this token
because that's something you could find
with a tool and it would save you it
would maximize how you use your Security
reviews um in in a better
way this last tip for develop
is um kind of higher level not
necessarily in the weeds um is
proactively trying to figure out how can
you increase security within your life
cycle how do you what are processes that
you can use um in order to find bugs
during development um such that your
bugs that found that are found future um
in kind of the auditing side or um the
kind of further security side um are are
the the big ones
um generally the smaller the code the I
mean the the bugs have less impact
within the system to fix um and so the
more bugs that you find while you're
writing your code the better for your
code all right this is kind of um
flip-flopping tracks because I am also
um or mainly security researcher now um
so I guess raise of hands how many of
you are security researchers or
interested in heading that
direction okay
um then let's get started um this next
tip is preemptively ask questions and
preemptively identify all of the
assumptions that developers are making
and this ties kind of into the previous
recommendation for Developers about
documenting your system nothing is
harder than trying to identify what did
you actually try to build in the first
place um a lot of the time I'll look at
a code base and then realize yeah that I
think that's what was intended I'm not
entirely sure um here's me looking at
the code base here's what I think it's
supposed to do but um it's really hard
to have that clarification and if you
make a wrong assumption during your code
review I mean you're you're you could be
missing a bunch of bugs um and and
issues within the actual code because
you misunderstood how it was supposed to
be used so for that I would
recommend collaborating with your
security team collaborating with the
developers um make sure that you take
the time and the effort to identify all
the assumptions that you're making in
your Security review um and make sure
that that's a lot with what how
developers intended to users to use
their
system all right this one is a bit of an
overlap as well um but essentially to as
a security re researcher building a
mental model of the code base um is
incredibly important because um and and
this um graphic is from uh the most I
guess Sherlock Holmes where he kind of
references um thinking about like
different con Concepts in terms of a
mine castle and where he can um kind
of figure out how to um categorize
information into this um kind of
strategic uh model that he can kind of
be able to parse through information um
be able to understand things and then be
able to bounce
ideas as a security researcher this is
super important just because um once you
have this mental model of whatever code
base you're looking at now you can start
to understand okay this is how um you
know this particular flow Works um this
is how developers intended um this
certain flow to progress um and then you
can look for deviations and assumptions
where they can might they might go wrong
um a lot of the times this helps with um
kind of taking a break and then you can
be able to really understand like
different impacts um of like different
issues and and especially a kind of
higher higher level view of the system
um understanding just like how the
codebase was built and how it works goes
a long
way all right this next tip is to learn
your tools as a security researcher
there's endless number of tools that you
can use um to verify whether developers
do are doing things correctly um endless
number of um different like fuzzing
Integrations verification Integrations
that you can check things and I think
there's far too much conversation about
which is better I don't think that's a
productive discussion um instead I think
it's more important for um security
researchers to really sit down play with
each of these tools figure out when does
when do they come in handy when are they
most powerful um and really learn how to
use them um I think there's also endless
resources on how to use these um and at
least for me as a developer I just have
so much fun playing around with these I
think
um the more you play around with
different tooling and the more you play
around with um comparisons between like
use for example like um fuzzing a code
base um or like uh writing unit tests on
a code base I think the easier it will
be to test the code um and playing
around with um the code base with these
tools that helps you in a different way
because with code then you can test with
test the code base you can kind of see
okay what are the different branches
within your function how do you invoke
certain um like if M um how do you you
know Trigger or revert and it really
gives you a good idea of how the system
works so I guess the T tldr of this is
really just play around with as many
tools as you can um and see where they
help you the
most as a security researcher I've
realized that um how developers intended
users to use their system never really
matches to how users intend to use it I
think that's just because um developers
have an assumption of you know this is
the one flow that users are going to use
and it's just this is this is it um and
users are always creative in terms of
arguments or just like the ways that
they call Smart contracts um any kind of
any potential deviation in these two
things can be um a fairly big bug um and
can result in like an impact in the
system um so it is one area to look
at my last tip is to lean on each
other's strengths I think um from a
security researcher side um I mean I I I
was kind of sitting in in both sides
before um but as a security researcher
they bring kind of understanding of you
know the security implication of in the
system um security kind of um tooling
and and knowledge there developers
usually understand how they want their
system to be used kind of the more um
strategic side and I think for a
security review you can really take
advantage of those two things um and
really collaborate with each other and
lean on each other's strength to
maximize or rather to shorten um the
amount of time it takes both parties to
to understand a code base and then to
maximize the number of bugs you find
during your
review all right with that I'll pass it
off to
[Applause]
Tino hello hello hello hi everyone let's
put the
stopwatch thank you hi everyone nice to
see you all here and thank you for
coming I know it's early some of you
went partying last night probably um
hopefully not too hard um yeah so the
idea is continuing talking about these
tips uh for security researchers for
developers um nice to see many
developers in the room next time perhaps
you can put like security researchers on
one side developers on the other and
like with throw each other stuff or
something like that just to get it
started uh but anyway yeah
let's let's be honest okay I don't think
many of us here I include myself we not
going to invent the next new big thing
right uh it's probably the case that we
are iterating on something that somebody
else in the past built or that somebody
else in the past
found so it might make sense to learn
from history and to learn from what
somebody else found or what somebody
else built uh to try to secure the thing
that we are doing that we are reviewing
so for example you will find uh
particularly in crypto that we are very
good at publishing things is not usual
in the rest of the security industry uh
to public audit reports you should take
advantage of that this is just one
example of Cypher Sol AIT where you will
find a basically a database of issues
that has been that have been reported in
the past by many security researchers uh
across multiple platforms auditing
companies if you don't want to use this
you can go know trailer bits I think
publishes reports open sing publishes
con intelligence publes Sigma Prime does
the same and I could go on and on and on
so I'm not saying that you should read
other reports like you read a novel but
probably you should at least scheme
through them if you are building a new
protocol H that I don't know it's a defi
laring stuff or some deck or some
whatever that you're building next uh go
see if there's some similar project out
there that has done similar things to
you that probably the answer is
yes and go read the issues and probably
you will find good stuff um just to
double check if you're not missing out
on something it's sad when we see in the
out there in the community the same and
same and same issues being repeated
again so please I don't know take a look
at this or many other resources out
there we already talked about this uh
but I just want to reinforce the idea um
particularly for for people doing
security research out here it's very
difficult to understand to what extent
you should go deep to what first time
you should go white uh there's no clear
answer there's never a clear answer uh
my only tip here is uh whenever you are
very mat in depths of a code base be
careful okay um it's very easy to get in
tangle in I know line 250 of that a
th000 line assembly code that you're
reviewing and you end up finding
something very cool that I know you can
do something very unexpected in that
function but there is it's very hard to
sum out uh because you need to find the
actual attack Vector you need to
understand impact in the project and to
understand impact you should have
context how many times have you found
something to then realize that well yeah
but nobody can exploit this um if you
are a little bit evil you might end up
reporting that still to the developers
just to fight with them and they will
end up telling you that well uh it's not
exploitable so zo out have context
understand where you are standing
understand the expected use cases uh an
issue could be an issue for you but if
the system is not actually expected to
be used that way I don't know if it's
not expected to integrate with that
other protocol that you're thinking
about or it's not respective to use that
token that you're thinking about your is
won't make sense so uh have in mind
these kind of
things di Mission returns uh are a I
know something that I struggle with and
actually I have questions I don't have
tips uh I will borrow tips from you if
you have some similar bullets to solve
this um I usually don't know to what
extent I should be chasing down bus I
mean it will depend on the kind of
Engagement that you're doing right so I
will talk about this later but auditing
is not back hunting and it's not doing
contest for example so to what extent
you should be chasing that bags um to
what extent you should be going into
that rabit hole when should should you
stop probably experience will tell you
something about
it uh you will start growing some
intuitions little by little on to what
extent you should be yeah going down
certain paths and not choosing others
then when it comes to reporting doing
Prof Concepts is also a place where we
lose ourselves as security
people um how much detail should you put
in that how
many I know how much infrastructure
should you be setting up to test that
bag you found in that bridge with that
connect a thousand layer threes and
fours and whatever uh sometimes it's
very complicated and you might end up
losing too much time on that I've
been sometimes like a week trying to set
up a whole test n environment to try out
an exploit uh just to realize that then
when I reported perhaps it wasn't the
case or the proof of concept it's too
complicated to run or I end up debugging
the my own proof concept instead of
debugging the actual code that I need to
review so again just uh questions to
think about things to consider either
and then the last one I'm not a very big
fan of uh this new security contest but
some people in the room might be um you
will find this escalation Wars if you're
not familiar with it essentially uh in
contest you will find people like
competing to submit bags at some point
in time there I think this is true in
all in many platforms but they all do
the similar things but not exactly the
same uh people will start fighting each
other just to um escalate their issues
and try to make them more or to fight
back the judges or whatever and you will
see like endless threats of people
throwing at each other um and
spending precious time on that while
they could be doing something more
valuable for the ecosystem um but again
I've been in some cases there and I know
the feeling and it's very hard to to
understand to what extent we should be
doing it uh but anyway dimin
returns
uh okay diagrams yes I love this
part as a security researcher I'm
a visual thinker so that means that I
often times find myself like drawing
stuff just to think about the things
that I want to do I also write a lot and
I will tell you all writing then uh but
let's talk diagrams now I use diagrams
to understand systems and this I and I
do different kind of uh level of details
in diagrams this was me for example
trying to understand account obstruction
uh in the past
uh and I ended up drawing this as I was
going through the code through
documentation and everything I was just
drawing stuff and trying to understand
what I was seeing in this case it's more
kind of an architectural diagram I don't
know I don't even think about it I just
write components and I write names and
and try to see which are which are the
actors how are the relationships and
this at least for me is very useful uh
perhaps for you too so take a look at it
and perhaps you you will find something
valuable then I do some other things uh
in terms of tyam I could go into more
detail with them in this case this is
was me just thinking about the them
buner defi this is kind of a set of
security challenges that I created this
is one of the solutions for one of them
so I was explaining this at DSS and I Ed
a diagram to explain the actual solution
so you will see me like doing function
calls and usually drawing where are the
funds and where we should be putting the
funds and everything this just one
example in real AIT probably I will be
doing uh bigger things such as
this h i I do go in depth sometimes so
this was me back hunting in ler um so in
this case I was reviewing main at
contract so and I need kind of to create
a mental map of how the contracts work
and how they interact with each other
and where are the addresses and then I
would use like uh yeah which are the EAS
in this case there's a multi there and
then I would try to understand how fees
are distributed and I also use diagrams
and I they would try to understand uh
story St layout and I would also use
diagrams and so on and so forth right so
uh you might say that I'm spending too
much time drawing stuff and not looking
at code but this is just the way I think
uh often times and I find this valuable
uh in many cases IED up finding bags
just by looking at diagrams and trying
to understand how actors and contract
relate to each other and sometimes I end
up finding finding kind of holes in my
diagrams so I realize that people can
call things that shouldn't be able to be
called
so yeah and well you can use whatever
tool right so you can use online tools
your whiteboards in your rooms in your
offices whatever that you that you feel
like
um moving out with the comfort zone is
another good thing uh that we should be
all trying to do in many aspects of life
but let's just keep with security
research uh I just put that picture of
that book because I like it if you want
to read it and give it a try uh it has a
chapter about the comfort zone so um if
you're a security researcher uh
probably sometimes you will yeah you
will find yourself uh Growing Experience
in certain fields in certain categories
let's call them of vulnerabilities or or
even
protocols uh but sometimes it's good to
do something else earlier this year I
was um I mean I've been for most of my
career I've been auditing solid smart
contracts uh so I don't have that much
experienceing notes and infrastructure
for example but earlier this year uh
there was a contest I think it was on
Cantina for blast and I had the chance
to either go for the smart contracts I
mean I didn't have much time so I had to
choose smart contracts or go for the
node H which was written in goang it was
a fork of
gu and I decided to go for GU H for the
fork uh and I didn't look at the Smart
contracts I missed H the all the fun
that people had with the smart
contracts um but I did have lots of fun
reviewing it um and I learned a lot and
I ended up finding issues and we did
quite
well but I wouldn't have I wouldn't have
said that I was a an auditor of Goan
code uh but I ended up finding things
and that only happened just because I I
moved out of the comfort zone and I
started learning go I had never read
anything about
golang um so I learned about it I did a
few courses I prepared myself I went in
there and ended up finding things and
even if you don't find things it might
be the case that you end up learning
which is always cool and the things that
you learn you can actually use in the
next contest that you do and little by
little you can specialize in that new
technology that you're
exploring um so I'm not saying you
should always be doing this otherwise
it's like you're not specializing in
anything but every now and then see
where you can do something else uh if
you're are a smart contract auditor see
where you can audit a node or the the
other way around right um just give it a
try and see and then you can tell me
about
it so writing I told you that I'm a
visual thinker but I also like writing a
lot uh two articles that I recommend
essays about the from from Paul Graham
that I recommend reading about writing
and importance of writing particularly
for thinking um I do very much agree
with idea that you only know something
if you can write about it and you can
explain that to something to someone
else by writing it and that's the only
way I'm sure that I understand something
probably if you follow me online H you
know that I write a lot and I publish
articles on on on the blog of the red
Guild and that's the way I think and I
spend a lot of time writing uh so when I
do AIT I explain my functions in writing
I take down notes and little line by
line and explain myself what the
function is doing and in that way I can
find bags uh because what I write
sometimes doesn't make
sense also when we are exploring a new
codebase it's the case that uh we
explore many different uh lines of
thoughts but you cannot be jamping
around uh many lines of thought right I
usually I'm single threaded so I can
only do one thing right uh so I write
down the other ideas I have and I don't
want to forget them so I write I write
them down and I come back to them later
in the next day or whatever and to
communicate I always say
that secur doing security for me is uh
particularly for Auditors 50% finding BS
and 50% communicating backs you might be
the best finding a bag but if you cannot
actually write a good report and
communicate that to someone else and
convince that someone else that you're
right about it it doesn't make any sense
so uh du L to write it's very very very
important and it's also somewhat fun uh
so I do recommend
that a particular strategy to find bugs
uh It's just sometimes going for what's
not tested
um what I sometimes do is essentially
jump into a test Suite see which are the
P functions in the contracts that are
never called and start exploring there
it's usually the case that whenever
there's a public function that is never
called from the test it could be yeah
it's sometimes the case that there might
be something at least at least to
explore in that
sense then what I would do is that I
take advantage of the ex existent tests
I modify them I hook into them I rework
them I bring them around I I do whatever
I want with the tests uh but just
because I don't want to be building test
from scratch right so I want to reuse
the existing test Suite that's what what
that's why it's very important to always
H take a look at them try to use them
run them and see if if it helps
you we could talk a little bit more
about this uh I don't want to extend
myself uh I do have some minutes left
according to Rajiv he told me I had some
extra time um so for me oing is not back
hunting but hunting is not contest and
contest are not aiting the skills the
mindset the experience the intuitions
the way that you play these games is
totally different and you might be the
best auditor out there I I consider
myself a good Auditor in the past and
then I moved to contest and I realized
that people play a different kind of
gaming there uh and perhaps I wasn't the
best doing that and about country is the
same right uh in aiting you will find
yourself doing client facing work you
will find yourself going deep and going
wide and going very detailed and writing
very detailed reports and talking a lot
with developers uh not necessarily
discussing but just thinking along along
with them just to to find more
vulnerabilities and backs and you have
access to to these developers often
times
you also feel the responsibility when
you're an auditor particularly if you're
leading audit you feel responsible for
what you're doing which might not be H
sometimes the case if you're just back
hunting right back hunting you're just
perhaps a Sol back Hunter you're uh um
shitless in your home just doing
whatever you want and looking at some
code sometimes you look it more you look
less you you might not feel as
responsible as other people uh um you
can go as deep as you as you want you
can just get one win and you're done
Auditors might need to find everything
it it's a very different mindset and in
contest well contest for me are just
like Madness
um some people find it fun uh sometimes
I do but uh again it's a different kind
of game you should be finding sometimes
specific bags that are more unique uh
you should be thinking differently about
how to report some people leave them
influence judges some people throw
at each other just to escalate their
bags I mean they are a different mindset
too so uh if you're an auditor perhaps
you're not a back Hunter and perhaps
you're not good at contest or the other
way around but choose your ground and
know what you're
doing uh I about to wrap up
so whatever ground you choose H try to
be professional we see lots of people on
Twitter um not representing very well
the security community in many ways so I
always try to share with people these
ideas of being assertive without being
aggressive stand your ground but not
necessarily being aggressive with
developers be empathetic to them and new
developers with have security research
too we try we try to always be as
thoughtful as possible we take our time
uh to think about the things we want to
report the things I want to explore the
things that we share with you um always
putting as much attention to detail as
possible
this is a big uh thing to me uh paying
attention to details in
reports to the code when I'm when trying
to find uh
BS so very being very thorough being
sometimes slow and being thoughtful
about what I do and always trying to be
kind to each other I I this is the kind
of the hippie part but trying to be kind
to each other and respectful uh we all
have uh we are humans we have friends
family problems we can get very
adversarial sometimes uh but as long as
we are respectful to each other uh and
we don't each other publicly on
Twitter uh sometimes it could be
necessary a little bit um but please
avoid those reports on Twitter
or you just public shaming somebody
somebody that is not answering your
report that you just submitted 15
minutes ago and it's ends up being an
informational or whatever uh so try to
be professional uh we're try to be like
big security Community
here wrapping up have patience
everything takes time particularly when
you're doing security becoming a
security researcher takes time finding
backs takes time reporting triaging
judging escalations let's not even talk
about how payment sometime takes endless
time so yeah it's a game of patience
lots of people coming to me what should
I do how should I get started how should
I find this this and that
and what I always do is be patient uh
because uh we are here for the long
run Rajiv you're up thank
you great good to see uh people sticking
around till the 30th tip so uh people
may be getting hungry but I would
request you to stick stick around for 12
more uh there is a fun quiz at at the
end with rewards which may be
interesting all right so uh the next 10
tips more uh memes I would say um I
would like like us to zoom zoom out
right so you've had fantastic tips sort
of covering both the security researcher
mindset good to see developers as well
so covering that as well and by the way
on that we need we need more people in
security so if you're devs then do
consider not just securing your own code
base um and having that attacker mindset
security mindset but do consider looking
into security getting into more of
security as well so in this case the
first thing is really both as a Dev as
well as a security researcher is to zoom
out and sort of
assess the protocol that you're building
or reviewing right first thing is I mean
look at this so Billy
somebody hands them or her um money
right but would like to sort of take
time to explain the importance of smart
contract security but of course you know
YOLO go and dgen mode look at what the
assets are put it into the vending
machine do some actions and then you
know make money or regret right so this
is I mean this may seem like fun but
it's all about the assets right I mean
that's that's why we're here all these
assets are being put on the blockchain
in U various
forms what are those assets as a
protocol you obviously will have a very
clear view as a developer but as a
security researcher this is the first
thing you need to see what tokens right
where are they being
held where is it entering the system and
more importantly where is it exiting the
system because attackers are really
looking to exit out of the system with
the these assets right so having this
mental model documentation of assets is
really critical and of course actors
right I mean these actors could be users
of your system could be abusers could be
attackers could be um developers
themselves in in the sense of you know
all the code that's gone in and
potential um
impacts negative impacts as well I'll
get into more more of that later it
could be even the governance right I
mean here we are talking about smart
contracts in general right so it could
be even the governance and how does that
how does governance as an
actor factor in to your threat model or
trust model so that has to be considered
and of course all the actions right so
what are what are the various actions uh
that can be taken by these actors when
are these actors uh when are these
actions happening when does it make
sense when doesn't it make sense right I
mean these these will be very clear to
the developers or the security
researchers once in the context of the
protocol but you really have to zoom out
and think about these very
consciously and how are these actions
impacting the assets how are they
impacting the actors and why does this
all make sense so that is at a 100,000
foot level I think that is really what
this is really what security is about so
if you go back I mean uh for for uh
those who are familiar with security
Theory this is really what an access
control Matrix is you have the subjects
operating on the objects you have the
Matrix of permissions right so this is
fundamentally what we are looking
at all right the second meme so you may
see sort of repeating
repetitive um things in the tips that we
have we've been talking about but that
this is what we are doing consciously to
drive these points home right
as a
developer you may have an expectation of
your ideal users right or the users of
your protocol but the reality is going
to be very
different and as a security researcher
this is something you have to pay you
know great attention to right again
users and
abusers how does this particular
protocol get normally
um I mean how does it function normally
what's the normal behavior but then that
is that is fine we need to build that
model but what we are looking at is the
anomaly right how can this go wrong now
not all anomaly is bad right I mean
obviously there are so many things U
that we don't intend to capture in the
protocol which is fine and not every
anomaly is a security issue right it's
really a small subset of that is what
what we call as bugs right but really
vulnerabilities that really impact the
system that affect the assets that
affect the actors drain it out and and
everything in between so this is
something that
is super critical that all the
developers should really be thinking
about right how is this going to be used
how is this going to be abused the
reality is going to be right more than
one user I mean the the monkeys on the
keyboard sort of an analogy right so
really pay attention to this and this is
not just the users I mean this could be
again extending to all the actors right
it could be the governance as well
you've seen whole bunch of governance
attacks where um it wasn't within the
attack the threat model to really
consider something like that happening
but that is really what happens and for
the users right I mean this applies
really to every scenario so as as a user
or a security researcher
one I mean we could expect uh on the
flip side a particular sort of a
behavior from the developers right but
of course we have scams we have Rock
pulls so even there the reality might
really not match what our expectation is
so for all the users developers and the
security researchers there's really a
message
here great so third one third
meme challenge assumptions I mean we are
saying this repeatedly in different you
know using different memes different
ways of saying it but this is really the
root of all
bugs right the assumptions made by the
developer about the user the assumptions
made by the security researcher about
the code base about the developer the
assumptions made by the developer and
the security researcher about the users
I mean all combinations right so this
is this is really the root
of anything that's wrong with security
right so question everything as a
developer
question question all possible scenarios
all the different ways that you know
maybe you have a design maybe you have a
spec from uh from your team but how can
this be used right how can this be
abused question everything every
scenario all that has to be captured
within your model and as a security
researcher again question everything
right I mean ask Nat mentioned uh tincho
as well about
questioning everything to yourself and
as much as you can to the protocol to
the developer team as well right because
if we do not understand as a security
researcher if you do not understand what
this is supposed to do how is this going
to be used we certainly cannot
understand how this is going to be
abused right so as much as possible
obviously practically there's obviously
a limit it's all time boxed so figure
out you know and this
uh depends on the model as well so if
you're doing a collaborative review you
know you have quite a bit of leeway in
terms of asking questions if you're
doing a contest maybe not as much if
you're doing a bug mounty again very
limited ways of uh sort of questioning
the protocol about every U knit and you
know Nitty Gritty detail that you may
want to know about right but try to get
an idea of who again actors actions
assets who is it what is it being done
when when and where right so that is
really critical question
everything and security is nothing
without discovering the misuse scenarios
right again repeating myself use and
misuse critical and abuse is really a
subset of misuse so figuring out just
the various misuse things is not going
to um you know do much as a security
researcher you have to figure out the
abuse cases and the abuse cases are
really the vulnerability ities we'll
talk about the impact in a bit and
really to map out what the attack
surface is right so for a developer in
this case it is really to reduce the
attack
surface of your protocol of your code
base reduce it so that I mean one way to
reduce it is to reduce the complexity
right reduce the number of U actions
that can be done figure out what is
really critical
there is a concept called guarded launch
you know maybe you can do it in
steps various ways to reduce attack
surface because if you reduce it then
the potential for abuse is much lower
right so the probability
goes
down and your actors and attackers I
mean we we are in the blockchain
environment right so in this case we
really looking at sort of um the worst
case scenarios from an adversarial um
mindset anything and everything can be
attacked and will be attacked and by
anyone who is a part of the system so we
really looking at a very uh High bar
right when it comes to who that attacker
is unlike the web 2 or the web 1 World
we do not have an good idea of who the
Insiders are and who The Outsiders are
who what is a characterization of uh the
the normal users of my system so it's a
really adversarial mindset um that
should be kept in mind when you're
designing coding and
reviewing great so um severity tincho
talked about this in the context of
bounties and and uh
contest this is probably more relevant
for the security researchers right if we
do not I mean we we great we found a
misuse abuse scenario but if we
cannot determine and communicate like
Ino said what the impact is then it's of
no use right I mean it's probably going
to be like an informational finding or
maybe a low severity one but not much
but quantifying that is super critical
and the way the sort of the rule of
thumb is to see
evaluate the assets are they being lost
are they being locked is it temporary is
it
oops is it uh permanent
is it does it apply to all the assets or
is it only a few of the assets is it
only the fees or is it the user assets
is it you know can they impact assets of
I mean assets that they own or can they
impact assets of all users there are so
many ways to sort of slice and dice this
right so that is critical I mean this
and and the good thing is I think the
impact is U objective I mean can be
fairly objective in terms of how we
determine it
but likelihood which is really the
probability that this can happen that is
trickier right is does this happen all
the time does it happen sometimes what
are really the conditions under which
this
particular um vulnerability can be
exploited that's really what we're
looking about right uh looking
at so that is um hard uh and typically
what ends up I mean that's where all the
escalations happen that Ino was talking
about and these conditionals there are a
whole bunch of Nesta ifs right that if
this condition is met and this and this
so you go on and I think realistically
the more the number of predicates or ifs
the lower the likelihood right so figure
out what uh the likelihood is what the
impact is and uh use that to sort of
quantify the severity of the
vulnerability that you're
reporting and on the flip side for the
developers who may be
sort of looking at these audit contests
or bounties right this is again I mean
if you're evaluating uh if you're one of
the judges or if you're on the team
looking at U any of these contest
results or Bounty submissions this is
something that you need to pay attention
to right and and it It's Tricky but it
is really
important great so for the star Star
Wars
fans it's really all about being
consistent for the developers it's about
being consistent with your
checks in different parts of your code
base on the various assets on the
various actors and
actions if these checks are
inconsistent then it leads to
inconsistent transitions right in your
protocol and those result in
inconsistent
State and that is again the root of all
bugs right I mean these may seem very
obvious very
simplistic but at a 100,000 foot level
that's what it really is right so if you
go back to the code that you're looking
at uh that you're developing or the or
you're reviewing look for these patterns
of checks anything that's done in one
place that is missing in other places
that is uh you know it's a big red flag
it's a good starting
point right
so web
3 well this is uh this is a meme adopted
from web 2 right and it's I think I've
seen it used in the context of
dependencies where the the small uh
block that you see marked out as bug is
really a dependency for almost
everything that you run but it is small
nobody really knows about it nobody
really knows when it was developed and
whether it's being maintained and
breaking that right could really bring
down the entire space so in the case of
web 3 I think um it is very similar and
I think it is even worse because web web
3 is not of sort of isolated from web 2
right it's really building upon web 2
and and there have been many talks here
that talk about the web 2 aspect of
security so we won't get into that
but the bugs in web 3 can be any
anywhere and really they're everywhere
at this
point so this may paint a very sort of
red nasty sort of uh uh picture uh very
pessimistic Outlook but I think we are
getting better right I mean it's it's
worse it was worse it also sort of
signals the maturity of uh the entire
stack the entire space but these are
getting better right and as we do this
we also add adding a lot more um lot
more codebase lot of you know a lot of
new infra a lot of new tooling so it's
sort of
um uh cat and mouse game right you you
fix these bugs but there are new ones
there's new code bases and there are new
bugs in
them so for for the developers I guess
the message here is that every line of
your code M codebase matters right so
just be very conscious about everything
that is getting into your code basee try
to see if it is really required or not
and for the reviewers for the security
researchers read every line that's not
enough read between the lines as
well and what this means
is what it's it's relatively easier to
sort of find bugs in the code that you
see but it's much harder to imagine
things to imagine bugs in the part That
You Don't
See right so do that and
uh and that even then it's on enough
right so it's uh it's almost um an
unreachable challenge for the security
researchers because you have to read
every line between the lines and Beyond
the Lines Beyond the Lines is really
about the dependencies that you see here
right it's not enough if you look at
what your code base is but all the other
code bases I mean we really building the
Legos of the future or the the the
financial uh defi blocks the future
internet 3.0 piure term right if you
want to build that
then they have to work together and if
they have to work together we cannot
afford to have security issues in the
glue that is connecting them right so
that is that is the real part here so in
the case of web3 smart contract
specifically you may be looking at
dependencies on oracles right I mean
dependencies on other protocols
dependencies on your web tooling all
those can have bugs and has to be within
uh your U uh threat
model right so next meme for all the
Matrix fans here bugs are really
everywhere right they're really there in
every code base it's it's pretty much a
matter of um what incentives are right
for the developers or the researchers to
find
them so the message here is look at
what's there and what's
missing for all the developers think
like an attacker right the security
mindset how can it be broken so that is
really the sort of the repetitive
message here and for the researchers
obviously think like that but also act
like a white hat right uh we can get
into more of those stories later on I
think uh yuran had
um had a talk earlier on with u talking
about bouny stories at the security
conference okay so this again is
invariance
Right a lot of security well lot of it
in the smart contract space in in your
code base boils down to
invariance invariance is another term
for properties
what properties should hold in your code
base what properties should not hold
good in this code base right and these
have to
be consciously thought about right I
mean this comes up in the context of uh
formal verification typically where
you'll have to specify the invariance
and then use a checker but then even
without
that as a developer before you write a
line of code right think about
what should what invariant should this
satisfy what are the properties that I'm
actually coding for
and document
it great if it can be a formal
specification fantastic right because
then we can use formal verification
tools but let's even lower the bar right
write it in plain
English what is my code supposed to
do that is super critical for all the
researchers and reviewers who look at
your code basee Nat talked about this as
well document
everything right put it in quote
comments inline comments Communications
is going to be super critical in the
space and all of us are sort of
repeating all this over and over again
because it's really all these
fundamental principles that apply so
readed as a security researcher read all
this hopefully the devs have written up
all
this ask
ask questions be direct in asking your
uh protocol teams or your on your
favorite contest or Bounty platforms ask
you may not get the answer but it
doesn't
hurt and ultimately try to infer some of
these if you don't get the answers right
so that's that's possible as well
there's a uh fantastic area of research
where you can actually infer inv variant
and a simple way of thinking about it is
inconsistent checks if there are some
checks if there are checks in some
places and not then it's either an
invariant or those missing checks are
sort of exceptional paths so try to
infer looking at clues in the code and
docs and so
on all right the the final tip is just
find it right I mean we tend to
um talk a lot think a lot but ultimately
it is really about
reading the code right and and the good
good part of the space is most of these
Protocols
are open source they have verified
sources so you can actually look at the
code base right and know that okay it's
hopefully the same one that was reviewed
was deployed look at the code there is
no buck free code it may not be the you
know critical criticals or the highs but
it may be the lows and the infos but
there are bugs right read the code find
the bugs and like all of us have said
both for devs and for
researchers I think success you know we
may think of overnight successes but we
don't see the sort of the we see the tip
of the iceberg but there is a lot of
preparation that people have done right
people have spent uh years decades in
different different ways practice and
then ultimately patience
so I have I have the pleasure of U also
sort of summarizing a lot of all these
steps we'll do that in the next two um
next two slides and then we will have
time for questions we have 10 minutes
and then there's also a fun
contest so quickly right for
devs before you code specify and design
and after and during you Code test
right so this is not I mean it it's it's
written as sort of a linear thing but
it's really sort of a cyclical thing it
it happens it's a helical model so do
that repeatedly think about assets
actors and actions actions think about
where assets leave your
system security mindset is critical in
this space both for devs and and the
security
researchers shift left which is a really
well-known thing in the space and all it
means is that let's not wait for you
know uh test in prod kind of a meme
right think about Security even before
you start coding for the
devs think about I mean that's that's
really what that's really the uh
environment we are in in in this case
right test properties trest invariance
use your favorite tool it could be you
know the the the provs we have some
fantastic ones from um uh the serator
approver use use fuzzing we have the
Medusa from um from Trailer bits use
simpler static analysis tools we have so
many of them as an example
Slither and if if you're U more into bug
bounties you have various tools there as
well use Foundry
use solo D to as an example to look at
some of the P to learn from the past
use glider to look at things on the main
net there are so many of these
tools play around with them right I mean
some of them may
really work for you some of them not and
for the devs obviously the buck bounties
and you know things may not may not
really matter uh for the devs but all
the various other tools right there are
so many plugins for your Dev
environments use those to test it out
there are testing Frameworks there are
ious extensions the key is to find your
tools and your techniques right and
there are we we I mean we lucky to have
a good choice think about the use and
abuse scenarios think about the
adversarial environment think about
defense and
depth right because if there is any
place where we require defensive
programming this is it right do not
assume that I have um you know I have an
um I have an array and it won't overflow
right or I have this code path nobody
will uh it won't be executed or nobody
will
um create a pool with this uh weird
erc20 token right do not make
assumptions right and for devs in this
case um yeah so won't repeat we're out
of time we want to save time for
questions as well but all these things
right and all these slides will be
available uh soon the video I believe is
being live streamed but the bottom one I
think is critical right we tend to get
overwhelmed but take care of your code
as devs from a security perspective and
more importantly take care of yourself
well with that thank
you cool so U I think we have questions
we can take I don't know if people in
the room have questions or or if they
have used the tool to put it up here but
maybe we'll start with
this hello hello hello we yeah all right
the first one um what do you think
regarding an issue in erc20 standard
discovered in 2017 which caused $15
million loss by ethereum users
which one is this
I
what I don't recall that one I don't
know okay excuse I don't have a formed
opinion about it thank
you okay while while that link is
getting posted I think we have one that
went up how do you say your process is
unique what do each of you do
differently from everyone else oh that's
a good
one um I would lie if I'm I would say my
process is unique
[Music]
um I don't think it's honestly I don't
think it's Unique I think uh well I
don't I haven't worked with these guys
side to side but um I do to some extent
our process might look similar sometimes
I think we might defeat initiating to
what extent we use tooling for example
that's one case in my case I don't use
tooling very much I'm very much a manual
reviewer uh but perhaps not Rajiv or or
Jonah might use some more tooling
sometimes okay go first okay so um I was
very interested in the to in this topic
last year or sometime last year like
different methods of approaching
bounties Audits and there there's a lot
of different ways of going about Audits
and security research but in the end
they're all not that dissimilar I think
for J's last slide is just read the Cod
um in the end that's kind of what
everybody ends up doing um Everybody
builds this like General mental
framework that
they add information into as they read
codes um writing specifications running
tools they are all just methods thinking
writing another matter of thinking about
the code but in the end you're all just
like mentally processing uh and yeah so
I don't think it's going to be super
dissimilar yeah I would Echo that I
don't think it's that different um I
used to do a lot of my reviews with
invariant testing and fuzzing um but I
don't think that's atypical um I think
if you put the time into really
learning how to use the tools um I think
anyone can really spin up like a fuzz
test um it's really just a matter of
kind of how complex um you want to get
with
that there's too many
tools should we pick that one um I think
uh n had a slide on this um doesn't
matter which tool you use just use the
ones that work for you um I feel like
that's very true there's a couple V code
extensions that are super nice I
personally don't end up relying a lot on
this kind of tool I use V code bookmarks
super useful uh but that's not really
security researchable obviously you're
going to use some syntax highlighting go
to definition type tooling um but beyond
that is really like what works well for
you um um and I recommend you try out
like all the different things um in
terms of researchers to recommend these
guys there are a whole bunch I mean um
just just go on Twitter um look
up and let let me look at the
publication right
um which publication so I would
definitely uh do a shout out to uh block
Threat by Peter from from coinbase so as
a publication so it's a I think a weekly
thing where all the threats in this
ecosystem are very neatly compiled so do
take a look at that if you're interested
and um if you're specifically interested
in smart contract bugs then the various
um reports from from contest from U
different project I mean different firms
like diligence they all have you
whatever publicly available reports on
their
soloed that com that compiles it so
those would be uh definitely some there
is a whole I mean all these security
videos right um recorded talks so there
was a uh defi security Summit DSS
conference last week and I think we had
pretty much every uh well most of the
leading researchers in the space web 3
web 2 anything in between every aspect
right were there all their thoughts have
been captured so just go to those
YouTube channels or wherever they're
hosted take a look at it uh so that is
something I would definitely
recommend I found the link by the way
you can find it in this thread if you
scroll down the comments okay I don't
know how to scroll down um not in
this yeah maybe yeah we'll we'll hang
around so you can show it to us offline
as well can yeah sorry I wanted to add
something about tooling um I personally
use Foundry a lot does it count as a
tool I don't know but uh I write tests
and I do fasing with Foundry uh that's
mostly what I do and yeah visual code
visual studio ctions and that kind of
things cool can can we go back to the
slide I I think there was just one slide
we needed to show for the
quiz so while it comes up so this is a a
short quiz it's really 15 minutes
and you don't have to finish it now just
look at the QR code uh it's eight
multiple choice questions there's a
small contract which was designed by uh
and this was designed by tincho it has
uh you know for for the devs and for the
security researchers there are some bugs
in these uh contract Snippets so if you
go to that link and if you use this
password you'll be able to answer the
quiz and uh the top
two top two participants will get
tickets to DSS next year DSS is the defi
security Summit the security conference
that happened last week here in Bangkok
so hopefully it'll happen next year as
well so yeah if you get a chance do take
a look it's going to be open for about a
day and any further questions so yes
thank you for sticking along any further
questions uh we're going to be hanging
around in oh there's one question in the
room
thank you can I explain the history of
the issues that was asked regarding the
erc20
standard can I explain it and ask you
for your opinion regarding the
issue I I'm sorry I don't understand
your question history of the erc20
attack the
erc20 uh problem that was asked in this
uh commments channel the erc20 standard
contain security flaw that the Fabian
vage the creator of rc20 standard
confirmed in
2023 uh it is classified as the lack of
transaction handling so the erc20
standard is designed in such a way that
uh when you are trying to send tokens to
a Smart contract which is not designed
to receive Tokens The Tokens are lost
permanently for example if you would
send ethereum to some smart contract
which is not imp which does not
implement the receive function or if you
will send the nft token to such contract
that doesn't that does not implement the
on ERC
721 uh reception function uh it will not
be lost but the ec20 token cannot be uh
uh handled on uh the contract's uh side
as a result uh if you send such tokens
to a Smart contract that cannot reject
them they will be permanently lost so in
uh 2017 this issue was described uh
there was 16,000 of dollars lost because
of this issue at that time in the next
year there were $2 millions of dollars
lost uh in 2023 there were $60 millions
of dollar loss because of this issue
because it is still not patched and uh
on 1st November
2024 there were $90 millions of dollars
lost and two days ago a user lost $25
millions of dollars because of this
exact
issue got it yeah I think uh we
understand it now so token sent to a
contract being lost right as a as
opposed to being sent uh accidentally to
a contract right
so I
believe I mean it is it is how it has
been designed so users actually excuse
me uh why is ethereum and NF designed in
another way and does not cause the loss
of money for users do we want to say
that the loss of money was designed I
don't believe so this is very specific
to Smart contracts right and it's not
nothing to do with the ethereum base
layer and it also is about how your
smart contract works right so we can go
deeper into this I think there's a
misunderstanding here so we can uh talk
about this but time's up but we also
want to take the last question in this
room uh thank you uh just very curious
uh uh perhaps maybe the three of you can
uh like describe how you approach a
fresh Cod code base where you studied
and like how do you map out and what
your workflow like thank
you how do you look appro a fresh code
pleas so I already answered the question
I think before so me personally I start
with the documentation because there's
going to be problem sometimes you
already find bugs just reading
documentation I think I saw a Twitter
message like or the other day where
someone actually did the same thing
found a bug reading just documentation
and then usually like Global scanning of
the code base and then for me I usually
take the go deep approach so I just like
spearhead for for the parts that I think
are uh vulnerable but I think that is
mostly a bounty hunting approach doesn't
work for auditing or yeah a let others
speak to that hey thanks for the
question uh so in my case um I will say
yeah documentation first uh with a
healthy dose of disrespect for the
documentation don't trust everything
that you read because it might be a case
that in the code doesn't match the
documentation so you have fun with
issues
there um and what I would also do is
just this is perhaps something personal
but I will just start with the little
Parts uh I wouldn't go first for the big
contracts where you have like all the
main interaction everything sometimes I
just start by the small libraries but
isolated things that I can then just
treat as black boxes in in the future in
the so I would start at the beginning
with those and then move up into
complexity yeah I would Echo
documentation I would also add um
starting to like find and identify
invariance from the beginning um so I
kind of start with that withd
documentation and then reading the code
finding some more invariance and kind of
iterating throughout that process um I
think over time the more you understand
about the code base the more invariance
you can find and very likely um the more
invariance you can
break thank you
[Applause]