Recently, we held a public GitLab AMA (Ask Me Anything) with the bug bounty hunter Vladislav Nechakhin (@0xn3va on HackerOne and Twitter) about why he hacks, how he hacks and advice for others looking to do the same.
A bit about Vladislav Nechakhin (@0xn3va):
Vlad is an application security engineer who helps software development teams create more secure applications. In his spare time, he hunts for vulnerabilities in bug bounty programs and tries to expand his skills and knowledge to become more advanced in the security area. Thanks to this passion, he now leads two open-source knowledge base projects for application security engineers. When not working or hunting, he tries to devote time to his beloved wife and for discovering new things through travel.
Check out the replay from our live Ask Me Anything session with Vlad:
Getting started
When you first started doing bug bounty hunting, was it easy to find "low-hanging fruit," or did it take some time to get into the right mindset and learn the tricks?
Vlad: It took some time! My first attempt was back in 2021, and even though I had been learning a lot, I wasn’t able to find anything special or remarkable. But then a year later I decided to try again, and it gave much better results. Honestly, I believe that I am still searching for an approach that works for me, and that there is no final point in this search. The more time you spend on bug bounty, the more it will open up to you. However, it’s impossible to reach a final goal and say “Okay, I now have enough skills to hack anything I’d like".
When hunting bugs do you tend to focus on individual companies, or do you focus on a single technology you might have more experience with and then look at what companies that could apply to?
I focus both on technologies and products that interest me. From my point of view, in order to find critical vulnerabilities you often need to dive deep into the system and understand what components it has and how they work together. I believe that developing this mindset is what allows hackers to grow. Moreover, you can see how this mindset works in real cases in articles by people like Sam Curry or the Assetnote team and other mature researchers. So in summary, I would say that I try to combine both approaches to achieve the best results.
What advice would you give to someone looking to get started with bug bounties?
This is tricky, and I’ve spent time thinking about this. I believe we all have unique experiences, mindsets, and knowledge bases, and it is impossible to recreate someone’s success. Focus on what interests you and create your own unique path.
Researching the GitLab bug bounty program
You often spend a lot of time discussing impact with the team, which sometimes has led to reports that have been closed then have been reopened. What are your thoughts around this?
I think it’s the responsibility of the researcher to show the impact as clearly as possible. Honestly, I do not believe that a security team can easily see the whole picture in a lot of cases. As a researcher, I would like to cover all the gray areas and explain my vision of the vulnerability. In many cases, a team may miss possible exploitation paths and ways of expanding the attack surface. Especially if you are reporting something unique, involving using new techniques or technologies. In other words, you just can’t expect that the team on the other side of the bug bounty program has exactly the same level of knowledge and expertise in a particular area where you have found a vulnerability.
This may not be a popular opinion, because many argue that post-exploitation and showing impact are often out of scope in bug bounty programs, and that the security team should evaluate risks better from the beginning. There is truth in this, I agree. In many cases, the actual business risks may be so low that the technical impact of a vulnerability will not matter. However, I'd say this is more of an exception.
Lastly, it does not mean that a researcher should drop all the data in a database to prove the impact of a found SQL injection vulnerability. I think the key is to find a balance between showing the real impact and actually harming the system.
What's your experience working with the GitLab security team in contrast to other program teams?
The GitLab Security team is one of the most mature teams I have worked with. In contrast to other teams, GitLab provides exceptional transparency.
It has been noted that you often lean towards code reviews in your reports, and that you often describe both the bug and the root cause. What is your approach to dynamic vs. static testing when it comes to GitLab or in general? Are you switching back and forth, or do you mainly focus on one method?
I tend to focus on code analysis, as I have a passion to read and review code. I find it interesting to figure out how the code works, and to actually discover the root cause of a vulnerability. I need to know why a vulnerability happened. However, in many cases reviewing code is not enough, and I have to turn to dynamic analysis, as well as debugging if possible.
Does the design of the UI influence the likelihood of vulnerabilities?
Well, first of all, I’m not a UI design expert. But however ridiculous as it may sound, it is actually quite important from an application security perspective to understand how a user interacts with an application.
For example, if some security settings are optional, a complex user interface will not increase the likelihood of using these settings by ordinary users. Moreover, if settings make the user experience more complicated, these settings will be simply disabled by most users.
This is especially important in critical situations. For example, say that you receive several email notifications that someone has logged into your account from an unfamiliar device. In such situations, a user should have specific steps to mitigate the attack, which, for instance, could be added directly to the email. For instance, maybe there could be a big red button to change your password and to set up two-factor authentication.
Among security design principles, there is “psychological acceptability” that says that “security functionality should be easy to use, and at the same time transparent to a user."
So, in summary, I think that UI and security actually are closely related and that needs to be considered whilst designing solutions.
AI is a hot topic at the moment, especially here at GitLab. Do you think it will make your life as a bug hunter easier, or harder? Could you briefly explain why?
I believe it is easier and harder at the same time. Easier because some issues that I stumble upon nowadays can be solved by using AI, like decreasing the amount of false positive issues while scanning.
However, it is also harder because AI is a huge gray area, it significantly increases the attack surface and complicates defense. The patterns and mechanisms that perfectly worked before should be reinvented and applied.
Getting to know our hacker
What’s your favorite weird food combination?
The weirdest combination I've tried is beer with salt and chili. This is beyond my understanding.
If someone wrote a book about you, what would the title of the book be?
“Strange Days”
Sock, shoe, sock shoe, or sock sock, shoe shoe?
Definitely shoe sock to complete the sequence of permutations.
Want to know more? Watch the replay!
Learn more about check out the YouTube live playback. If you want to dive deeper, you can see all of our Ask a Hacker AMAs here. A huge thanks to everyone who joined live on the day, who submitted questions, and of course to Vlad!
Keep up with Vladislav Nechakhin by following him on Twitter and checking out his hacktivity on HackerOne.
About the GitLab Bug Bounty program
The overarching goal of our bug bounty program is to make our products and services more secure. The program is managed by our Application Security team. Since launching our public bug bounty program in December 2018, we’ve resolved 1396 reports, awarded more than $3.5 million dollars in bounties and thanked 563 hackers for those findings. You can see our program dashboard at https://hackerone.com/gitlab.
Cover image by Fotis Fotopoulos on Unsplash
