Inti was recently speaking at Detectify Hacker School, an event for customers where we have hacker talks and user cases presented to the audience. Afterwards our security researcher, Linus Särud, sat down with him for a hacker-to-hacker interview discussing how he got into bug bounty, his unconventional bug hunting ways and his take on why the European market is an ocean opportunity for bug bounty hunters.

L: So to start with, who are you and for how long have you been doing Bug Bounties?

I: My name is Inti. I am from the small and beautiful country Belgium. I started doing Bug Bounties quite early in 2011 when Google had just started their program. I did not know much at all back then. I copied and pasted payloads and knew that if I got a pop-up I would get money. I was basically a factory worker.

L: Why did you get involved in this field?

I: I have always been into hacking because I like cheating. I was not that good at video games, did not really have the skills, but I was good at cheating.

That is the way I got into hacking; I bought a PlayStation Portable, and I knew nothing about video games either, but I wanted to play Mario. You can obviously not play Mario on PlayStation devices, unless you downloaded a jailbreak for the device but then I couldn’t find any for the version I had.

Determined, I continued searching until I found a guide on the internet, they said to “just crash your device and post the crash log online”, so I did that. I tried stupid ways of getting it to crash. Custom fonts, video previews, stuff with subtitles. Nothing worked, until I decided to create a website with what seemed like a million of As in the title, saved it as a bookmark and all of a sudden the PlayStation crashed.

So I posted the crash log online on that forum because I could not read it myself and then to my surprise it was removed even though all the other crash logs were still online. Then I got a private message saying that I had found Remote Code Execution, and was like “wat?”

I had found RCE on Playstation Portable, probably one of my best bugs, but I did not understand why it worked. I found it by accident and now I wanted to understand how and why. I was interested in what was happening behind the scenes, and they helped me write an exploit for the bug together. That is how I got into hacking and then later on Bug Bounties.

L: Have you always had this luck doing Bug Bounties?

I: I am not sure when I evolved from being a script kiddie to where I am today. It is probably because of the payouts; in the beginning all my reports were terrible, but then I noticed I could make way more money by actually investing more time in my proof of concepts.

If you would look at my HackerOne inbox you can see that in 2014 it was all shitty bugs, in 2015 a bit better, in 2016 I started going to the live hacking events and it soon got better and better and now I am here. I definitely used to be a total script kiddie.

“I want to get pentesters to try Bug Bounty hunting on their own, and attract more talent in Europe to get involved.”

L: So you went directly from high school to doing Bug Bounty?

I: Yep, I have no proper education in security. I worked for a radio station for a really long time which had nothing to do with security, but I liked it. It was a 9-5 job, I would arrive at home and could hack some companies.

I do not have advanced technical knowledge either. I think there’s a common misconception that you need to be the best programmer in the world to find bug bounties. I can program, but I am a cowboy programmer writing spaghetti code. It works, but I do not even believe my code to be secure.

L: Could this explain why you are known for the weirder logical bugs rather than strictly technical vulnerabilities?

I: So basically, I do not go for specific targets. I want to find something new, not a duplicate (a vulnerability that’s already reported). Because of that I do not look for XSS, SQLi or other common vulnerabilities and I am not technical enough that I can do white-box source code review.

There is this grey area where you have logical flaws and stupid tricks that sometimes end up being very critical. That is what I do. I look for functionality. For example, with email bouncers I knew in my head that there must be something wrong with these and I just need to find it. Then you can take a piece of paper and map out all possible scenarios. I go from a behavior, try to invent an attack scenario, and from there figure out a proof of concept.

Many hackers look for bugs, I look for attack scenarios and then for the bugs. And it works for me as I get fewer duplicates. The downside is that I spend time researching ideas that sometimes yield nothing.

L: Give us an example of how you work differently:

I: For example when I focused on web shops, I created an inventory of programs, stack traces, and so on. Whenever I found a vulnerability or configuration mistake that could affect many, a golden goose-bug as Mathias calls them, I would look over my Excel sheet and see which vulnerability applies to a company I’m targeting.

I love edge cases and logical flaws. I have also been looking into namespace hijacking which has become increasingly popular. That is what I like about my bugs, they are never really technical. I do not face that much competition in logical bugs, and there are a lot of them out there.

Scanners do not detect logical bugs, because to detect them you need context, you need to understand the application and the business logic. While everyone is looking for XSS I am just reading the docs.

L: I like the part of scanners not being able to detect many logical flaws. That makes me curious, how you would recommend companies to protect against vulnerabilities then?

I: So first off, now I am making a little bit of promotion of you here, but for me Bug Bounties are like a really expensive scanner. Why would you pay hundreds or even thousands of euros for a simple XSS that Detectify could have found? So I would definitely go with something like Detectify for that stuff. Things anyone could find, of course we should automate that.

For this reason, I don’t believe Bug Bounty hunters should not spend that much time on those. Detectify and other scanners will also evolve, and they will catch those XSS. Most companies would save money by using a scanner first. I think that Bug Bounties will evolve more and that is why I have invested so much time in it for contextual bugs. I’m trying to put myself as many steps ahead of the scanners as possible.

I know that scanners are faster and even better than me on other things, so why would I try to compete in the same way? The thing is that scanners cannot detect logical bugs. Okay, to some extent they can, but they are not there yet. There are a lot of ‘if that and this and that’, and most scanners cannot understand context, which is why I look into those areas so I do not face competition with Detectify.

L: What do yo do if you come across a common vulnerability like XSS?
I: If I encounter it of course I would report it! And to give you an example, I will look for XSS, but with strange attack vectors. Take the one with email addresses for example – I read the RFC, saw that they included comments, and that it could include an XSS-payload. Then I start looking for it, because it is special.

Did you know you can smuggle payloads in a valid e-mail address using round brackets? Thanks for the tip, @securinti! #BugBounty #HackWithIntigriti pic.twitter.com/i1OMbzjBfl

— intigriti (@intigriti) December 27, 2018

Another example is that I recently started sending HTML-emails to random email addresses. Some of those email addresses, for example support, would just take the content of the email and show it in some web interface where it is rendered. That would make my blind XSS-payload work.

As a third example, I once sent money to a couple of companies and in the transfer description of the wire transfer I put an XSS-payload, to see if it would fire on financial systems. It would cost me one cent per try, but if it did fire it would do so in their financial system. … turns out the payload actually did fire, but in the banking environment and the bank did not have a Bug Bounty program.

L: Haha, I actually did something similar once. Transferred money through a third-party where you could do transfers using phone numbers as identifiers. I put the XSS-payload in the message field, and while it did not work in the receiver’s app, it did so in the bank. The bank had trusted the data to be safe as it came from the trusted third-party and not directly from the user.

I: Yeah, that is the thing. If it contains user input, it should never be trusted.

I had a similar experience once when I went through my billing statements I got an alert popup. I tried to reproduce it but it did not work when I re-sent it through their app or web interface, however, when I went back to the physical machine and it worked!

Edge-cases like that is what I love. If I have a secret, that is the one. Do not look where everyone is looking, because you will get a duplicate.

L: If you try to exploit XSS, the vulnerability is validated when you get the popup. However the results isn’t always clear with more creative vulnerabilities, does disagreement over the impact ever happen?

I: Yes, I have been there. For example with TicketTrick, there was a support vendor that had many vulnerable customers and the support vendor could easily fix it. But instead they decided it to not be their problem, but rather their customer’s.

Sometimes that happens, and while the Bug Bounty money is a motivator, I will not be upset if they are not paying because of a disagreement. There are people trying to fight with program owners, but from what I have learned it is not worth it. I just remember it and do not hunt on that program anymore and keep in mind that I have a great variety of payouts.

For example, when subdomain takeovers were new, some companies would pay $100 for it and others $10,000. It can be good or it can be bad, but that is also something that makes it more exciting.

As for reactions, I like sharing those “WTF-moments” with the vendor. When you report an XSS or a standard bug, they will thank you and we move on. When you are reporting really weird bugs, you can get responses such as “what is this even?! Yeah, we are definitely going to fix it”. It is fun to evoke that kind of reaction.

L: On that note, you once reported a behavior to Facebook which they considered a non-issue at first, but you got it approved. Those instances must be a bit hard to handle?

I: Yes, they did not agree, so I asked if I could publish a blog post about it. I am not a douchebag, I will not threaten them with a blog post just because the security team does not agree with my report, but at that time it was more for the greater purpose. I believed that people should know about that behavior I found.

It was not to punish Facebook and I made sure to get approval from Facebook before publishing it. But then media was on fire about it. People started calling Facebook and I ended up getting a bounty for it. I felt a little bad for receiving that bounty, because then it obviously looked like I was a bit of a douchebag.

L: I agree with your choice to publish it, but the line in between threatening with a blog post and doing it for the greater good seems quite thin. What advice do you have for someone who finds themselves in a similar situation?

I: Yep, it is a fine line. Since they actually fixed it though, I am still glad that I did it. When I write a blog post, which does not happen a lot, I always make sure to check with the company and get their permission to do it. I think that it is important for security researchers to not be douchebags. Sometimes you disagree with the team, and sometimes your expectations do not align with reality. We can get really angry about it, but sometimes there is nothing more to do about it.

Many people are starting to do Bug Bounty full-time now, and I am not sure that is a good idea. It is still Bug Bounties, and sometimes you can’t expect more than a simple thank-you for submitting a security bug. My problem is that there are occasions where bug bounties are getting too commercialized, which makes me question the true intentions of having the bug bounty program.

L: How can Bug Bounty hunters and companies become more aligned?

I: I am running a Bug Bounty platform myself, Intigriti, and we have a good relationship with our customers and with our researchers. The Bug Bounty industry definitely has some challenges. For example, there are companies that want to start a Bug Bounty but only have $10k to spend.

What do you do? They want to use your platform and researchers sometimes do not understand that the company can run out of money. How do you explain that to the hackers? They have put energy into finding bugs in the company’s platform and the company previous paid out for it, but not anymore.

I think it is important that HackerOne, Intigriti, Bugcrowd and everyone else think straightforward to fix the issues that we are currently facing. In the end, you want everyone to be happy. It is an important balance, and we need comprehension from both sides.

Companies should recognize the time and effort researchers put in and we are really strict about playing fair with researchers. Working with Bug Bounty-programs and customers has enlightened my perspective as a researcher. I have learned a lot about how things are behind the scenes compared to when I was only a researcher and caring only about my payouts.

L: It’s cool to see your journey has brought you here! How long have you been with Intigriti?

I: It is about a year now. We are not aiming to be the biggest platform at the moment, and we are aiming to be fair and personal. We would rather be a good platform than a big platform. I want to provide a consistent and personal experience that benefits both the researchers and the customer.

The X-Forwarded-For header turns out to be a perfect place to hide your blind XSS or SQL injection payloads, according to @_zulln. Thanks for the tip, Linus! #BugBountyTip #HackWithIntigriti pic.twitter.com/qeGYNwlPnj

— intigriti (@intigriti) February 7, 2019

Image: example of Intigriti engaging security researchers

L: Going from Bug Bounty hunter to managing the Intigriti community, what had been the most interesting learning from being on the platform side of things?

I: As I researcher you only see parts of it. For example, if you submit a bug and two months later, it is still not fixed, you are wondering why the company has not fixed it. Now I get to see the other side. A company could have people problems, or any other kinds of issues, or things that they are trying to fix but do not have the knowledge to do.

You get more context, more explanations and understanding for the vendor, while as a researcher you can only see that your bug is not yet fixed or that the payout is lower than you had expected. That is also why I think we are going in the right direction with Intigriti, being more transparent and personal.

Sometimes when we make mistakes, because mistakes do happen, we try to compensate for it. Sometimes I even call researchers to say, “okay we see this, but because of x and y we need to adjust the severity”. I think that is way more personal than just seeing a change of severity in the report.

Bug Bounty-platforms cannot provide full certainty of payouts, since it is ultimately up to the customer, but I want to provide a transparent experience for researchers and I think that solves a lot of problems. We are working towards the same goal, Detectify as well, to secure more companies. I am a researcher at the other platforms as well, I love the platforms, but I think Europe is different.

L: Europe different? How so?

I: You know it as well, the mindset of companies is different.

We need a good European approach to Bug Bounties because the legalization is different. You cannot directly import the American way of doing it, but you still need to have a consistent experience for the researcher, regardless of the target is European or American. It is a bit of a challenge but we are getting there.

L: Does that affect your user base of researchers as well? Do you have American researchers as well?

I: We do, of course everyone is welcome! At this point, we do have more European researchers.

In the US, the idea of adding a Bug Bounty program is not new, while European countries are starting to make it legal which means there is a lot of potential talent as well. I know just based on myself, on the bugs I have found, and that I am far from being the best researcher in the world.

L: In what ways are you trying to activate the community and find new talent?

I: We are trying to look for new talent and support the community. On Twitter for example I am trying to build a community of a close group of friends that will help each other to get better.

I want to get pentesters to try Bug Bounty hunting on their own, and attract more talent in Europe to get involved. It is new, and it is always a challenge when you want to introduce a new concept.

Every country is different, and that alone is a difference from the USA. In Europe you need to re-do the process all the time. Another thing is that everyone speaks a different language. If a Portuguese website wants a Bug Bounty but all their content is in Portuguese, the chance of getting many researchers to look at it is quite low. We can better match programs and hackers instead of throwing random invites.

L: You have been talking about Bug Bounties as something relatively unknown outside of the US and there is still a lot of room for new talent to join. How does someone new to Bug Bounty hunting get started?

I: The main challenge is that there are a lot of people looking at a small set of public program, and that makes it hard to find bugs. I would suggest that people start to look for their own stuff, not what everyone else does.

A lot of people want a guide, “here is how you approach a target”, like how you would do with a penetration test, almost like a checklist. But you cannot do that with Bug Bounty; if everyone got the same checklist, you will only get duplicates.

For tips and tricks on ethical hacking, check out our articles from the Detectify Crowdsource community.

I think that for new people the first step is getting your first payout. It is a tough step because the chance of getting a duplicate as your first report is pretty high, and we probably lose out on many people there.

My advice: if you are a researcher and want to secure your payout for the next 5-10 years, start looking for custom bugs, logical flaws, and other things scanners or other researchers do not look into. That can lead to more impact, you will find new types of vulnerabilities, you can get speaker events, write blog posts about it, opportunities are plenty. It is more about your mindset and being open-minded to try stupid stuff or something unknown and not follow a checklist.

L: Final question! You just held a presentation during Detectify Hacker School. How did you actually get in contact with Detectify?

I: I go to the live hacking events organized by Hackerone, and there is a bit of rivalry between Team Sweden and Team Belgium, a friendly fight. We started to talk about it and I said I was working on a new presentation and they invited me over.

I am super stoked to be here, it is my first time in Sweden. It is one of the countries I have wanted to visit for a long time, looking at startups and technologies it seems interested compared to many other countries.

Find out more about Inti:

Twitter: @securinti
Inti’s blog: https://medium.com/@intideceukelaire

Detectify collaborates with handpicked white hat hackers like Inti de Ceukelaire to Crowdsource vulnerability research for our automated web application scanner. Sign up for Detectify and start your free 14-day trial today!