The Bug Hunter's Guide to High-Quality Reporting

Transcript

so morning everyone uh I'm abas and I have been a smart contract triager on imuni so imuni is a leading bug bonti platform for smart contracts and blockchain so I will be presenting topic on bug Hunter's guide to high quality reporting so using my own triaging experience uh I will be sharing what are those qualities that makes reports truly exceptional so let's dive into the topic so the whole agenda of the talk is

divided into two parts so I will be doing a high level overview of five key qualities of a great report then we will be exploring each of these quality with uh good examples verus bad example to see like how it goes so starting with the one of the first quality is uh the neat and clean title uh and the whole purpose of having this neat and clean title is it should summarize the whole issue so just by reading the title itself you could uh get the whole picture around the issue and uh the next we have this bug description where uh it's all about like

what the bug is and where the bug occurs within the code base and one of the key qualities the white hat follows who submits a great quality of reports is they always explain uh the issues with uh with doing a comparison between the expected normal workflow of the functionality versus the malicious behavior around the functionality so this is really helpful when it comes to bug bones so as a triager and as a judges are not much familiar with the code bases new code bases so having this expected Behavior versus uh malicious behavior functionality it it makes a lot more easier to uh understand the whole issue around

the uh around the bug and uh the next thing they do is they use the proper formatting so whatever the option the platform offers uh like bullet points or the markdown options so they use all the options with the whole purpose of increase increasing the readability uh and then next thing they do is they follow this proper referencing of the code so we know that bu submission could get complex uh because you have to go uh you have to explain the Nate structure of the code so going inside inside of the function going into another internal function so it's really important to keep the flow and explain each of each of that flow with a proper referencing of the code

lines so uh that's that's the bug description the next key quality is uh White hats always go beyond the attack surface they always focus on the impact uh so one of the example is let's say the white had reported a vulnerability where he mentions he found a reeny vulnerability in a specific function that's cool but what's the impact outcome of having this attack Vector like what damage he could do to the protocol or the user of the protocol that's what the impact is so they always go beyond the attack Vector so instead of just focusing on

the attack Vector they go and determine what what is the final consense like consequences of the impact that attacker can achieve so that's where the impact comes and the next we have this proof of concept so beside just submitting the code POC uh high quality reports often they provide uh dependencies that is required in order to run the POC and as well as the in setup unit in order to uh run the POC so also it's really important uh to have this POC output within the submission because uh it's super helpful for triers and as well as judges so looking at the P output you

can reproduce uh the uh like you can understand the whole issue around the issues like without even reproducing in most of the cases so it's super helpful to have this PC output fi uh within the p uh the last thing they determine is they think about any feasibility limitations so whether uh that could affect the course of the exploitation so they think about are there any limitations uh that could uh interfere with the course of exploitation so they be very open transparent and think about like what are the walk arounds like uh they can bypass this feasibility limitations so these are the high level overview of uh five key qualities of a

great report on on in the next slides we can explore each of these quality with some of the examples so starting with the title uh here's the bad example of a title which totally focuses on the attack Vector which says uh delegate call vulnerability in a proxy manager uh which does not give much of the context and here's a good example of the title so good example of a title is always a mixture of three composition that is like attack Vector then the source then we have the final impact outcome so here unprotected delegate call is the attack vector and source is a proxy manager is

the contract then we have this delegate function within the proxy manager and then it leads to the griefing So reading the title it should sum up the entire issue so you can get the whole picture around the issue uh next we have this bug description uh which it's really important to keep the bug description neat and clean just explaining what the bug is and where the bug occurs within the code base and also explaining this uh uh doing a comparison between this normal operation of the functionality and versus the malicious uh behavior of the uh functionality to just draw the difference like how it

deviates from from a normal operation and the third we have this impact so here's the bad example of impact or this white hats often do so whenever they submit their impact uh like in the case you can see uh the white had reports there's a reeny vulnerability in the withdraw function where he mentioned like which can lead to unintended behaviors and unauthorized State manipulation uh which leaves you a mystery like what are those intended behaviors and all so here's the good example of impact so using the same example of reeny vulnerability in a withdraw function uh the white had wrote like uh he it could

result in an impact of direct theft of funds from the contract uh then we have the bad examples of Po's so generally we see only two cases uh the first one is a lab grown po where the white hats develop the poc in a very control simulated environment just to demonstrate uh the attack vector and the vulnerability around the issue but it's not uh really applicable in a real world scenario so it's not actually demonstrated on actual code base so we don't accept that as a PC because it's not uh real world feasible uh then we

see a lot of this onchain Fork modification so here are the two examples of it uh where white heads go and actually go and modify the storage of the contract they go and modify the storage to Whit list thems uh to perform certain operations uh which is totally not acceptable because that's not how the actual conditions where are on the uh main net deployed contract uh then the another example we have this uh fundry cheat sheet cheat code they use uh I call this as unlimited money glitch where they meant like lot of token Supply uh Capital uh

just to demonstrate that act we do accept the cheat codes but it should be practical uh they should always provide the source like from where they are going to get the uh Supply so it's not like uh using the uh Capital which is not actually feasible within the ecosystem so so here's the uh examples of bad po uh then the last we have this feasibility limitations so feasibility limitations are uh to think about the uh think about the questions that uh that could interfere with the exploitation of the issue so the questions you could consider like uh

how cost effective the attack would be to carry out for an attack like how much the attacker is investing into the attack what are the capital requirements he is putting there and how much profit he is getting out out out of the attack and things like uh are there any specific conditions the attack uh attacker need in order to execute the attack or if the attack uh is being done for a long period over the multiple blocks are there any chances of risk of detections or are there any timeline for execution so you can always determine this Factor based on like the gas cost the attack is inquiring and as well as

the capital requirement the attacker would need in order to carry out the attack and things like the M Market slipage effect uh on the profitability the attacker would be making so and there could be many factors depending on each and every uh different uh scenarios and cases so the whole purpose of this having feasibility limitation is to be very very open transparent to the project that yes there are some limitations and also think about what are the work arounds they could come up to bypass those feasibility limitations uh finally here are the advantages of high quality reporting so

we have seen like high quality reporting often leads to faster rewards it's mainly because it makes U very life easier for our triers and as well as as the projects to go and understand the issue and reproduce as well as this leads to a faster uh resolve resolvement of the issue because it removes the whole hassle of back and forth communication to gather the more information and often we we have also noticed that high quality reports Al also leads to a very high end rewards it's mostly due to the effect uh effects of the efforts the white hat is putting into the submission and uh also there has been potential uh chances of getting

the Goodwill payout like even if your submission is getting duplicate or uh or if it's a know issue the projects always uh they go ahead and they always do a good willll payout for your efforts over there and lastly the white also build this reputation this trust and this in this gives them a more opportunity where uh more opportunity from the project side to get him involved in know some private audits as well and PR private programs to get him participate just based on the high quality submissions he submitted so yeah so these were the five key qualities and uh the advantages of

high quality reporting so that's it thank you