Table of Contents
vraj is a security researcher. We spoke about what makes a good hunter, how to use psychology in bug hunting and how he lost cryptos earned as a bounty.
There are hundreds of hunters in the Yogosha Strike Force. There are those who excel technically, and those who stand out because their psyche makes them formidable attackers. And then there’s vraj – Vishwaraj Bhattrai – who shines in every way. He is currently #4 on the Yogosha All-time Leaderboard, and #5 on the 2022 Leaderboard.
At Yogosha, everyone who has had the opportunity to work with him loves him. This guy is not only brilliant, he’s also kind. So when we wondered which hacker to interview next, the answer was obvious.
How long have you been into ethical hacking?
Professionally, I’d say about 6 years. But I got into ethical hacking before that, I mostly self taught myself by reading books and going to internet cafes during school days. I think I was around 19 and started learning about phishing. I started exploring it for fun, and later on I got really into it. After that, I did my bachelor in computer science. Meanwhile, I was also practicing and upgrading my skillset in various aspects. Then, I chose it to be a profession, because it was challenging, and I mostly enjoyed the creative process of breaking things – even though technically we don’t break them, we just show how they were already broken. It was just like a puzzle for me.
You’re a bug bounty hunter and a professional security engineer. So, what’s the best part about working in cybersecurity?
What I enjoy most is being able to fulfill my curiosity, and to have creative freedom. Everyday it could be a different system or environment, where you can experiment your thoughts and learn.
As a bug hunter, it’s really enjoyable. I just go and try whatever comes into my mind. There’s no limitation, no restriction. Still, you have to practice safe harbor, you need to ensure you’re not violating any of the terms. But that’s a good part, being legally and ethically invited to test things.
When you work as a security engineer, you have to secure things being built around. You need to threat model well and understand the attack surface for the features and services before things are even built. It changes your perspective, you have to see more from a defensive angle and while testing the system, you have to think like an attacker. But more than that, you have to take actions earlier to make the system more secure and resilient, so that similar issues won’t happen next time. I also get to write the defense for my own attacks, and guide developers to not screw up things, which adds up in my learning as well.
As a security engineer, you have to be on both sides where it’s mostly one way as a bug hunter, but you have more options and freedom to explore outside the box.
And what about the worst part of being into bug bounty?
I would say burnouts. If you have too many expectations, or if you’re doing bug bounty full-time. But I wouldn’t say it’s that bad, it just comes with the game. It’s the nature of it.
Uncertainty is one thing, but that can be eliminated over a period of time, when you develop your own methodologies. Also, you kind of make an agreement with yourself that this is a part of the game. After that, it’s smooth. At the end of the day, it’s really in individuals’ heads.
There are some days where you’re not hunting, and you don’t even know why you don’t. You have to take a break, and then come back. It’s also important to have different systems to test to avoid boredom.
On the bug bounty programs side, I would say response time and the overall communication. They’re hurting themselves if they take too long to respond, and by not providing regular updates. People will no longer be motivated to submit reports, because of such experiences.
What’s your methodology when approaching bug bounty?
I’m not a heavy tool guy, I do basic in app recon work. If you give me an application to test, I’ll just sit with it. I will understand how it works, how it authenticates users. I’ll do it old school, analyzing it feature by feature. And maybe I’ll find a dozen cases of how to bypass that feature. And I will enjoy it, because that’s where my creativity comes out.
Another thing I’ve been working on recently is optimizations. There are too many people hunting in the same space. You have to be quick. Let’s say someone can craft a report in 10 minutes. Could you do it in less time? So I’ve created pre-made templates, for the same issues that I look for, and written plugins and custom rules which will suggest exploits or hints to test particular scenarios. I think such methods will reduce your overall time, and will help you to have your submission valid.
For a wider scope, I will definitely go with automation and recon work that will increase your leverage. You also need to experiment, and add new detection logic into the setup on a timely basis.
Is there a type of vulnerability that you particularly enjoy hunting?
Mostly business logical issues. The ones that will have the most impact on the business, like account takeovers, payment issues, race conditions. Then I would test for IDOR and access control issues. Lastly, I would test for technical issues like injections, XSS, CSRF, SSRF depending upon the features available. These are the Top 3 categories I always look for, because that’s where you get your first hit. Once I get that confidence, I go more for the variants of similar vulnerabilities.
I do hunt for the variants. If I get a type of bug, then I’ll just try to relate where else in the entire application this could have been also replicated, but in a different way.
Let’s take the example of a banking application. Let’s say that person A wants to pay person B. If I want to pay person B, I should be able to select my account and the other person’s account, and then I should be able to send the money.
But what if, as an attacker, I can reverse the law of transaction? Can I get the money from user B account by altering the from and to parameters? And if so, where else can this be coming up again? Maybe it could be in the refund system, where ?from= parameter could be of bank internal account and similarly you can test remittance, raise a transaction dispute functionalities.
Variant hunting will give you more bugs. Even big companies, like Google or Facebook, adopted this practice very early. It’s difficult to fix individual cases of vulns due to their large code base. So you write a detection rule for a specific case, and then run it into the entire code base to find the same bug in multiple places, and mitigate them immediately.
Again, my primary lookout would be business logical errors, because that can’t be automated with any software. That’s pure human thinking. You can use Burp Suite and technical tools, and they can find technical issues in automatic fashion. But logical bugs cannot be found using any tool, mostly using your brain.
Other than that, I look to chain bugs up. I like chaining smaller problems and building more critical cases. For Example:
What is the bug you are most proud of having found?
One of them was in a crypto-currency exchange, where I was able to change the wallet address of any user using IDOR. And then I could chain it with CSRF (Cross-Site Request Forgery) so that I could initiate payments, get someone to transfer money. I’d say it was a very easy bug, but an impactful one. Usually access control issues, IDOR are simple, but when they work… their impact is high. So this crypto exchange paid me a bounty with coins of theirs, but I have to see where that wallet is. I kind of lost it… it was 3 years back.
I also found a few IDORs in Google Play Store, and another where I was able to download a paid APK for free. For those issues I was rewarded with a vulnerability research grant by Google. That was motivating. Another time, I submitted a bug to a famous airline, and they rewarded me with a lot of Miles. So now I can travel for free for sometime, that was cool!
You’re from India, and you have submitted vulnerabilities to companies all over the world. Do you see a difference in the way bug bounty is approached, based on the home-country of organizations?
Yes. It mostly differs in countries where economies are different. I have found that security is taken seriously, no matter the level of issues, in countries where there is higher compliance. Let’s say the European Union, the US, primarily the western side where there are strict data security laws in place.
In India, laws are pretty relaxed compared to European countries. We have to improve our laws regarding the overall cybersecurity posture, but things are changing. We have pending discussions on the Digital Personal Data Protection Bill 2022 which is a progressive step compared to the previous years.
Bangalore is considered as the Silicon valley of India. The majority of start-ups are here, and many of them are taking security seriously. They are launching their bug bounties, and there is at least a general security cautiousness among them. But still, we have to go a long mile. Hopefully things will get better with the new privacy laws.
We also have a lot of teens and graduates who are now keen on cybersecurity. They are participating in CTF as well as bug bounties and learning programs. There is a significant growth in local security communities as well, which are helping and guiding new folks to join the game. It’s been a blast here for the past 3 or 4 years, and I’m optimistic that participation will increase.
Is there any advice you would like to give to new hunters?
Understand web technologies. I think knowing more about how the web works will make you a better hacker than anyone. Understand DNS, protocols, web browsers rules or if possible read RFCs to find hidden attack surfaces.
Also, learn a language – PHP, Python, Java. Try to actually develop apps and features like login and signup , literally from the ground up. Learn how data is stored into the database, and where it is shown to the user. This will give you an idea of how data actually propagates.
Once you’ve developed something, try to break your own application. That’s how I trained myself before getting into bug bounty. I spent 7 or 8 months just brushing up on these things, and I am still doing it.
Then, I think practicing different classes of vulnerabilities is important. You can practice it in your local lab. Sit down, experiment, combine two classes of vulnerabilities, and see what edge you can get. Taking notes is important. Today I might hunt on one platform, and I will learn something about it. Tomorrow, if I get a similar situation, I won’t be able to recall. But I can go back to my notes.
So now I make graphic notes and mind maps.
- Start taking notes and put your unique learning from each hunt there;
- Don’t skip the basics and revisit concepts often when in need;
- Try to think from the developer’s point of view. Where might he/she have made mistakes?
- Experiment with new tools and techniques, improve your recon work;
- Stay consistent, improve daily by reading blogs, Twitter or learn from fellow researchers’ wisdom;
- Take breaks, revisit the same endpoint with a fresh mind if you are not feeling productive. Don’t force it;
- Reflect upon where you can improve. What’s your leverage over others?
- Don’t test systems which you are not allowed or invited to test;
- And at last, don’t lose hope. My first 20 bugs were not accepted before my first valid entry. It took me 2-3 months for the first valid submission.
So changing your perspective on things is important?
Yes, in a way. When reviewing code, I also consider the behavior differences and knowledge of the developer. It’s a theory, nothing fancy I would say, but it works. I call it behavior hunting.
Let’s take an example. For a past program, I looked up on Github at what people have committed to. You see how people write code. And with a little bit of experience, you can know if a person is new to the team or not. Then you target the person who doesn’t write security aware code, the person who can screw up. There’s a 99% chance they’ll be back.
So I wrote automation around it ,“Please, alert me each time this person commits.” And I got an alert every time, and my system would just look up for the previous rules I’ve written. If there was a mistake, I obviously had a bug there. That’s your edge right there, where you can take leverage off. And even seniors make mistakes you know!
You are basically using their psychology. How knowledgeable they are. They might not be experienced in writing secure code, or secure queries to avoid SQL injection. It’s really about reversing their psychology. Sometimes you will also find fights in the code comments like “please do not touch it” or “this is a code to execute commands securely” – that’s enough to grab your attention.
How do you think an organization’s internal teams should approach bug bounty ?
Internal teams do test their products and services on a regular basis, but bug bounty helps them in covering the gray area which they might have missed. So it is equally important for them to allocate resources, and invite security researchers to test their systems from different perspectives to uncover surprises earlier.
The attacker’s side is more relaxed. But when you’re in the organization, maybe as an engineer or consultant, you have to think on both offensive and defensive grounds. I think you have to be paranoid.
Security team should be monitoring their assets, constantly upgrading their detections, their skillset, and gaining wisdom from the breaches so that they are better prepared next time. They must also be aware of the latest CVEs trends and apply patches accordingly for the outdated libraries . Security is not an easy job, especially if you have a small team.
It also depends on the company’s priorities and culture.
- They should have required access, team and budget for running the bug bounties;
- They should spend a good amount of time testing the system under review before making it live. It should not be a hurry up game. Most of the time dev teams reach out to the security team at the last moment, which is not a healthy practice;
- The security team must have a say, a kind of veto to take the best decision possible within the company’s interest;
- They must be heard and shouldn’t be suppressed, because they are there to tell before things go south.
What do you think makes a bug bounty program good?
As a former program owner myself, I think the points below will be useful to others:
- Acknowledgement: You should give quick acknowledgement to the researchers after receiving the bug;
- Clear communication: Whether the report is valid or not, it should be given with a reason so that the person can improvise next time before submitting the report. I enjoy when the person on the other side is asking questions and seeking clarification rather than just abruptly closing a report, or not allowing a window for dialogue;
- Payout size, bonus: If the payout is high it will naturally attract more folks into the program;
- Proper scope representation: What is accepted, and what isn’t. It should be posted so that researchers and teams don’t waste their valuable time.
- Payout on triage: Don’t make them wait, if the bug is valid, pay them on triage.
- Large scope: A wider scope of assets to experiment with will be attractive, such as wildcard domains , desktop apps , mobile apps…
What’s the thing you like the most about Yogosha?
I would say there are some good programs here, they give responses and payout on time. Key things I like are regular invites, payout on triage feature, Hunter Survival Games and the reachability of the team. You don’t have to bash on social media. You can just reach out to the staff and they’re always keen to help. They want you to work. If something doesn’t work out, they will be able to help. Overall my experience so far has been smooth and I am looking forward to ride along.
Where do you see bug bounty in the future, maybe 5 or 10 years from now?
Security will always be required with the growth in tech and so does bug bounty. I feel there will be more diversity going forward, people will not be just limited to hitting APIs and doing mobile, web, IOT, native security. For example Web3 came up. Who knew that people would be building their own crypto currencies, doing Solidity audits? Similarly, space security looks cool with the recent developments in space such as Starlink. Gradually, people might shift towards space security too. There is already a program called Hack-A-Sat for satellite security.
The dynamics of traditional security testing have changed though. It’s becoming more tool centric, because of competition or maybe systems becoming more complex. Hunters have to build their own tooling and automation to compete. Going forward, we need to research and focus more on new classes of vulns which are still hidden under the surface, of which others don’t know about yet. This will give us leverage over others, otherwise it will be tough to survive in the game.
Also, we will see more independent players in the scene. People who don’t want to be in a specific job like arrangement, and really want to hack without obligation. Going forward, I feel AI will play a major role in either helping us or replacing us in security. It’s about seeing how people will gradually evolve to overcome it..
What do you do for fun?
When I am not working, I like to listen and follow up rising artists in music, mostly Indian hip hop genre and Coke Studio, sometimes watch movies on the big screen. Occasionally I try to produce beats.
You can reach out to Vishwaraj on Twitter and Linkedin. He also writes about his rants and findings on his blog, and sometimes shares his learning on his Youtube channel.
