Meet the Hacker: Peter Jaric, Software Developer: “I got two board games for the first bug I reported” – 10 minute mail

Our Disposable mail Crowdsource hacker Peter Jaric is a well-established profile in the developer community in Sweden, organizer of Javascript meetups, and a bug bounty hunter in his spare time. We asked him about his interest in security, his latest submissions to our bug bounty platform and what he thinks would be the perfect vulnerability to add to Disposable mail Crowdsource.

What are your experiences with bug bounty and responsible disclosure programs?

I have been working as a programmer for almost 20 years and nowadays I develop web stuff for Uppsala University.

When I was younger I heard about other students who hacked phone systems and things like that, but even though I found it cool and interesting, I never figured I could do it (and I am not of the criminal persuasion anyway).  Around 2012, when I first heard about this thing called bug bounties, I could suddenly hack stuff in a totally legal way. I found that very exciting, and still do.

One of the first issues I reported was a CSRF in a Swedish web shop that did not have a bounty program, but I got two board games as a reward. I think their immediate positive feedback made me appreciate this hobby from the very beginning. I still report bugs to them now and then but during 2012 I almost exclusively reported bugs to Nokia, who I believe was running one of the first bug bounty programs of the kind we know today.

I think it’s a fun hobby and some extra money now and then is always fun.

I also run the Swedish Slack group “Bug Bounty Hunters Sweden” (yes, it’s a cheesy name, I know). Everyone who is interested in the bug bounty scene and understands Swedish at least a little is very welcome to join the group.

In your opinion, what differs Disposable mail’s Crowdsource from other bug bounty programs?

I think there are several differences:

  • For bug bounty programs you find specific vulnerabilities that mostly exist in one place, but on Crowdsource you take a broader view and look for more common issues.
  • Another difference is that, in contrast with most bug bounty programs, you don’t have to create fully functional prototypes. Instead it seems to be enough to describe the issue in just enough detail for Disposable mail’s developers to be able to create a scanner module.
  • Finally, normally you get one reward per bug you report, but Disposable mail Crowdsource’s payout model is based on every time Disposable mail’s scanner finds an instance of your issue, you will earn money.

What have you submitted to Crowdsource and why?

Almost all my current submissions concern misconfigurations, for example open admin interfaces. I have used many of the affected systems professionally which has inspired me to see if I can find any open instances on the web. I’m an avid Google dorker, but lately I have grown very tired of the “I am not a robot” checkbox. 🙂

Do you have any tips for new researchers when submitting vulnerabilities to Crowdsource?

Do not be afraid to try! At first I thought I had to implement the module myself, but when I finally submitted my first idea for a module I realized that it was very easy. The Disposable mail staff are very nice and helpful.

What would be the perfect submission to Crowdsource according to you?

A very common Remote Code Execution vulnerability.


Are you interested in joining Peter and other security researchers on Disposable mail Crowdsource? Drop us an email: hello [at] detectify.com and we’ll tell you more, or check out this blog post where we have explained what we look for in a Disposable mail Crowdsource hacker. 


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the Hacker: Yasin Soliman “The bug bounty community motivates me hugely” – 10 minute mail

One of our latest Disposable mail Crowdsource hackers is Yasin Soliman, a bug bounty hunter from UK, who has been passionate about IT security since a young age. He was our most active researcher in September, so we decided to learn more about the guy behind the 23 submissions (!). We asked Yasin about his interest in security, the first bug he ever reported, and his role models in the security community. 

Tell us a little about yourself; who are you, what do you work with and when did you start hacking?

My name is Yasin “ysx” Soliman, and I’m from the UK. Since a young age I’ve had a passion for information security, but I first became familiar with security research and bug bounty programs back in late 2015.

Driven by the pervasiveness of online technologies, I soon gravitated towards web application security, and six months later filed my first bug report.

Tell us about the first bug you reported.

The first bug I reported was in a HackerOne public program. After thoroughly reviewing the target’s client-side code, I happened across a set of interesting directories intended for the organisation’s customer support team. Further inference led to the discovery of several ‘homemade’ endpoints for support tickets, which led to the disclosure of user submission data. The issue was promptly triaged and remediated in under six hours.

What are your experiences with Bug bounty programs?

I signed up for a profile on HackerOne and Bugcrowd back in December 2015, but struggled to land my first submission for several months.

Over time, I developed awareness of different vulnerability classes and how to compose effective reports, in addition to researching on the Google VRP and other non-platform targets. On that note, I’d strongly recommend having a read of the HackerOne guide on this topic if you’re getting started.

During the course of May this year, I entered the Synack Red Team screening process for web application researchers and proceeded to pass the assessment phases. It wasn’t possible to proceed at that time due to a personal situation, but I look forward to commencing work with Synack in the months ahead.

What motivates you in your bug bounty hunting?

The bug bounty community motivates me hugely. To be part of such a supportive and inclusive network of researchers has a profound effect on my research outcomes. The challenge and thrill of bug bounty hunting, ability to develop income, and opportunities for skill development are definitely motivating factors too.

Do you have any role models in the bug bounty community?

Every day I come across incredible case studies, findings, and writeups. It’s hard to name a few! I frequently follow the research of Frans Rosén, Masato Kinugawa, Ruby Nealon, Jack Cable, Inti De Ceukelaire, Sean (zseano), Ben Sadeghipour, and James Kettle.

Your favorite source for the latest security research?

Nowadays I come across a large portion of research over Twitter, reading researchers’ blog posts (like those above) and the latest news from bug bounty platforms. In addition, the Full Disclosure mailing list often contains informative content.

You have been a very valuable researcher on Disposable mail Crowdsource and submitted many modules of high quality, how come?

After being accepted into the Crowdsource program, I came to strongly value the innovative platform model and emphasis on creativity. Having the opportunity to build proof-of-concept modules for well-known systems – such as WordPress and Joomla – means that customers can benefit from continuously automated discovery. I enjoy working with the Crowdsource team to investigate new apps, plugins, and tools – especially focusing around bypasses, XSSes of various classes and other logic issues.

What makes Crowdsource different from other bug bounty programs from your perspective?

In my view, Crowdsource helps you conduct research with a wider-reaching approach. After finding a vulnerability in a commonly used system, the Crowdsource team help develop your proof-of-concept into a scanner module. For every detection picked up by the continuous Disposable mail scanner, you receive a reward based on the severity and impact of the bug, and can compete with the Crowdsource community on the Leaderboard.

Find out more about Yasin
Twitter: https://twitter.com/SecurityYasin
Personal site: https://ysx.me.uk

Are you interested in joining Yasin and other security researchers on Disposable mail Crowdsource? Drop us an email: hello [at] detectify.com and we’ll tell you more, or check out this blog post where we have explained what we look for in a Disposable mail Crowdsource hacker. 


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

[VIDEO SEMINAR] Magento security from a hacker’s perspective – 10 minute mail

Have you ever wondered how a hacker would analyze and attack a Magento website? We picked the brains of two ethical hackers to find out. Linus Särud, 18, and Fredrik Almroth, 27, share their best insights and advice on Magento security to help you keep your Magento store safe from hackers.

What you will learn in 15 minutes:

  • How Fredrik Almroth hacked one of the world’s largest e-commerce sites.
  • What any Magento website owner should know about security to be able to keep up with black-hat hackers.
  • A step by step-explanation on how a hacker would analyze an e-commerce page.
  • What the most common Magento security issues are based on our exclusive security data research on 30000 Magento sites.
  • What to do if you are hacked.

Get the free video seminar
Sign up through this form, and we will send you the video immediately per email, so that you can watch it whenever you want. We require double opt-in. Remember to check your spam filter if you don’t receive the confirmation email. And of course, the video seminar is for free!

magento-seminar-featured-image_720

About the hackers 
Fredrik Nordberg Almroth (Twitter: @almroot), 26, is internally known as “Godfather of Hacking”, since he has basically hacked everything that can be legally hacked. Fredrik has been appointed Security Expert of the Future by Symantec, and was one of the persons behind the famous read access on Google production servers hack, which earned him a bounty of 10,000 USD.

Linus Särud (Twitter: @_zulln), 18, started his career in IT security at the young age of 13. He has found serious security security flaws in Google’s system, written about IT security for IDG Sweden, and now works as a Security Researcher at Disposable mail in addition to going to high school. At Disposable mail, he is responsible for extensive security investigations like how top domains were vulnerable to email spoofing, writing articles and guiding customers in the support.

Send me the free 15-minute Magento security seminar

Sign up


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the Hacker: Gerben Janssen van Doorn: “If you want to pursue ethical hacking, start by understanding XSS” – 10 minute mail

Gerben Janssen van Doorn, a 21-year old ethical hacker from The Netherlands, is one of our Disposable mail Crowdsource hackers. He smiles when asked about his first bug report, “a possible XSS”, reported to Yahoo about 4 years ago, but a lot has happened since then. He has quickly become one of the most skilled security researchers in the community, currently on HackerOne’s Top 10 List, and a very appreciated member of our Crowdsource network. In this interview, he shares his best advice on getting started with ethical hacking, favorite sources for security, and method when looking for vulnerabilities. 

Gerben-Janssen-van-Doorn- Disposable mail Crowdsource

Tell us a little about yourself; how and when did you start hacking?

I am Gerben Janssen van Doorn, 21-years-old and besides hacking, I am doing a masters in organisational design and development. When I was around 15 years old, I used to play around with PhotoShop quite often which led to a part-time job where I did the marketing and web stuff for a small retail company. Here one of my tasks was to replace ads to make sure they wouldn’t expire. I got so bored of this task I ended up learning PHP to automate the task for me. Out of curiosity, I read more and more about web vulnerabilities, and started to secure my own script. When I eventually found HackerOne and noticed I could make money doing what I loved, I stuck with it.

Tell us about the first bug you reported.

Haha, the first bug I reported was a “possible XSS Vulnerability” to Yahoo on the 9th of March 2014. I didn’t provide any PoC, but my report mentioned certain characters being unescaped between script tags. Two days later (11 March), I was able to exploit the vulnerability using a new line and reported this separately. It is interesting going back to my old reports and realizing how much you learn using the feedback of HackerOne and the programs. I can remember googling the difference between XSS and CSRF at the time and not being able to understand it ;).

What methods do you use when you look for new vulnerabilities?

Today, after close to four years of hunting, I’m still amazed by some of the findings the bug hunting community shares. While I do know all of the “standard” OWASP vulnerabilities and related issues, the websites you are testing are rarely standard. You often need to do some creative thinking to get to the high severity bugs. Examples here could be vulnerability chains or nice recon techniques. Thus, to keep up with the other hunters you need to keep reading and try to find security problems in creative ways.

While a lot of security research in the bug bounty community is focused on subdomains nowadays, I like to focus on the main domain. In my experience, it is true that subdomains are often more vulnerable, however they often do not have the same impact as vulnerabilities of the main domain have. Thus, I focus to dive deep into the domains that are critical to the program/client, which I do by analyzing their JavaScript files using LinkFinder or by using specific Google, Github, StackOverflow or DuckDuckGo searches. When testing specific endpoints I often let the context decide how I am going to start. When seeing ID=3, I’ll test for SQLi, XSS and IDORS for example, but if I see url=http://www.example.com/ I’ll focus more on SSRF or RFI.

What are your experiences with bug bounty programs?

Almost solely positive. If I don’t like a program because I feel the process is unfair in any way, I just move on. Bug bounties are a buyers market and my opinion is that it is easiest to navigate through it by focusing on your own performance and the programs you like, instead of wasting time on programs you don’t like.

What motivates you in your bug bounty hunting?

The way I see it is that I got interested and keep being interested in bug bounties because I really like breaking software. The money allows me to spend a significant amount of time on it.

Do you have any role models in the bug bounty community?

My role models in the bug bounty community are those who are either very skilled or those who share a lot of information (or both of course). I feel like naming names is going to exclude some awesome people but many whom I met during H1-3120 are on that list.

What unites the white hat hacker community according to you?

It is hard to put your finger on it, but above all I think the bug bounty industry is so young that many people who are very involved believe in the concept itself and want to push it further together. You need a tightly knit community for that. Secondly, harder bugs are rarely trivial and thus often require advice from other hackers, which is why many people work together.

You’re currently ranked #10 on HackerOne – is your next goal to be #1?

No, it is not. First of all the HackerOne leaderboard is great, especially with the additions of signal and impact, however reputation in itself doesn’t mean too much. Furthermore, I’ll be done with my studies this June and haven’t decided yet whether I’ll be doing full time bug hunting or whether I’ll be working for an organisation.

What is your favorite source for the latest security research?

For me that would be blogs from skilled bug bounty hunters. These blogs are often very practical and allow you to get an insight in the methodology or thinking process of these guys. For example the recent Disposable mail writeup of the ACME TLS-SNI-01 vulnerability by Frans Rosen was insane.

What advice do you have for anyone who wants to pursue ethical hacking – how do you get started?

I often advise people to really understand XSS first for multiple reasons. First of all, XSS teaches you the basics of the importance of user input sanitation while showing both the input and the output of the payload. Other more complex bugs like RCE, SQLi and SSRF basically rely on the same principle but are often lacking output and thus exploited blind. Secondly, XSS is by far the most common bug in web applications which makes it relatively easy to find and thus easy to improve on.

What makes Crowdsource different from other bug bounty programs from your perspective?

Crowdsource allows the company to tap into knowledge of many security researchers, while the bug hunters get access to a large network of companies that are potentially vulnerable to the bug they submitted. In this sense the main value comes from its facilitated network. Secondly, Crowdsource is unique in the sense that it allows you to submit vulnerabilities in almost any widely used software application. Sometimes normal bug bounty programs exclude third-party software vulnerabilities.

What would be the perfect submission to Crowdsource according to you?

Unauthenticated remote code execution in a widely used software application. Besides the type of bug a good submission should include enough information to reproduce but not too much so that the task becomes time consuming for the review staff.

Find out more about Gerben:
Twitter: @gerben_javado
Website: 
https://gerbenjavado.com/

Are you interested in joining Gerben and other security researchers on Disposable mail Crowdsource? Drop us an email: hello [at] detectify.com and we’ll tell you more, or check out this blog post where we have explained what we look for in a Disposable mail Crowdsource hacker. 


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the Hacker: europa: “I always trust my gut when I get the feeling that something is there” – 10 minute mail

Meet the hacker europa, a white hat hacker on the Disposable mail Crowdsource platform. He is based in Italy with a great passion for infosec and relatively new to the bug bounty scene, but seasoned in infosec. We asked him about the kind of bugs he likes to find, why he joined Crowdsource and how persistence helped him turn a duplicate finding into a bug with 8 different bypasses.  

Meet the Hacker interview with europa

Tell us a little about yourself; how and when did you start hacking?

I’m Alessandro, also known as europa, and I’m an infosec aficionado from Italy. I took my first steps in infosec at the age of 12, back in 1997, via IRC channels #hackita and #hack.it on IRCnet, and never really stopped since. I coded exploits back when you could remote root almost anything by sneezing in its general direction, moved to reverse code engineering to derive WPA PSK keys for some Italian internet service providers, then onto more reverse engineering in video games and malware in order to code anti-cheat tools. I dabbled in CTFs for fun, and moved onto bug bounties because realized I could essentially do real-life CTFs and get paid for it. That’s a good 21 years of passion!

You started bug bounties hunting not that long ago. What have you learned since you started?

True, I started back in September 2017, if my spreadsheet doesn’t lie. I’ve documented my bug bounty process on Medium and every time someone mentions that Medium post I think to myself, I should really update that however there’s just too much knowledge to put into words that I’ve pick up along the way! Back when I wrote my first post, I had a fairly decent understanding of the reconnaissance process thanks to the work of Nahamsec, and Jhaddix, but I still hadn’t found my own flow yet. Some of the things may still apply but are superseded by either more efficient processes, built anew, or moved around. For instance: building or customizing wordlists for domain recursion against a particular scope using hosts found previously; curating wordlists of previously found bugs and their URIs; moving the FDNS parsing from my local machine to Amazon Athena; building a powerful regex to parse content against sensitive data during the recon phase, and the list goes on.

“… its “fire & forget” approach ensures that companies can reap the benefit of continuous testing against systematic issues…” – europa on what makes Crowdsource interesting.

What kind of bug do you enjoy finding the most?

I’m a simple man, I like escalating innocuous reflected cross-site scripting issues to account takeovers, data leaks, sensitive API calls abusing lenient CORS policies, and so on. I also enjoy finding some god-forgotten asset somewhere deep in the scope, building the perfect wordlist using entries from Github, and Google against that particular framework, finding all those nice endpoints, and spend the night filing reports: SQL injections, XXE, SSRF, XSS. I definitely have so much to improve still!

Based on all the bugs you have found, what advice do you have for website owners about better web security?

Run a bug bounty program, and If it’s sensitive, keep it offline. Also don’t commit your keys to the repo. Don’t trust user input. The web was a mistake.

In April 2018, you combined eight different bypass techniques in a report to Rockstar Games. How do you motivate yourself to keep going as you can never be sure the last step is going to work?

Back when I first started, one of my earliest reports was to Rockstar Games, surely guided by the impressive $1,000 reward for a stored cross-site scripting findings on their SocialClub. After a few days of work I was able to find one using a pretty simple bypass: a tabulation character between the angle bracket, and the HTML tag. I was over the moon, but that ended pretty quickly when a few hours later the report was marked as duplicate. Albeit calmly (I was slightly livid), I requested feedback about the outcome—I wanted to make sure I was being treated fairly. The analyst was impeccable: they didn’t have to reply, I wasn’t entitled to an answer, but they did and they were fair, explicative, and understanding. That moment largely changed in my approach to this field: respect is always due on both sides, and I always trust my gut when I get the feeling that “something is there”. You just know when there’s something to find—that weird response, that WAF tripping and removing some characters, that JSP endpoint you found in a minified javascript. Sometimes you get the feeling that it’s just a matter of not giving up—case in point that report, depicting 5 or 6 different stored XSS on the Rockstar Games SocialClub, with progressively harder bypasses.

Finally, as a Crowdsource hacker, what makes Disposable mail Crowdsource interesting as a platform?

Sometimes I happen to stumble upon a finding displaying a footprint wider than just the current asset, something more systematic that might apply to other targets as well, targets I can’t test on because they’re not part of the platforms I hunt on. That’s where Disposable mail Crowdsource comes into play: its “fire & forget” approach ensures that companies can reap the benefit of continuous testing against systematic issues, whose real-world impact has been vetted by skilled security researchers like @_zulln and @almroot. As a hacker I’m a big fan of automation, and automation that periodically rewards you for your past research without lifting the same finger twice is amazing. Plus, all the published research on the Labs blog is a goldmine!

Find out more about europa:

Twitter: @eur0pa_
Medium blog: https://medium.com/@europa_

Are you interested in joining europa and other security researchers on Disposable mail Crowdsource? Email the Crowdsource team at [email protected] or learn more on the blog.


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the Hacker: EdOverflow, motivated by community and knowledge sharing – 10 minute mail

EdOverflow is known for contributing a bunch of stuff: active in the community, one of the people behind security.txt – a standard for structuring responsible disclosures, bug bounty hunter and a member of Disposable mail Crowdsource.

We got a chance to quiz him about security.txt, his motivations for being involved with hacking communities and why he chooses to report to responsible disclosure programs without bounty rewards:

Why did you propose the security.txt standard?

As a security researcher, I am familiar with the difficulties with finding a vendor’s security-contact details. This inspired security.txt, a proposal that aims to minimise the time needed for security researchers to find contacts. The project primarily attempts to solve this problem by making it as simple as possible for anybody to set up. Someone with little technical knowledge can follow along and create a text file that adheres to the specification with minimal effort.

Have you learned anything about responsible disclosure since then?

The legal aspects of coordinated disclosure, most notably #legalbugbounty by Amit Elazari, have been particularly eye-opening for me since I have no background or prior experience in this area of the security industry. Her work has caused a major shift in how the bug bounty community view bug bounty program policies. It has made me more aware of the risks involved and how to provide bug bounty hunters with a secure platform to communicate their findings without fear of repercussion.

You also spend a lot of time sharing knowledge in other ways. Can-I-Take-Over-XYZ and bugbountyguide.com are two examples. What motivates you to spend time on this?

Working on projects allows me to put my skills to the test, meet new faces, and get feedback from various members of the security industry. All of these factors motivate me to keep creating projects. In addition, I often find myself actually needing these tools and projects I build, so I could see why someone else might benefit from them. This is why I usually publish my work on GitHub and other platforms that allow others to easily access my work and make contributions.

What advice do you have for anyone looking to advance with hacking?

Start by becoming a problem solver. Read technical articles and books, and whenever you stumble across a problem and challenge yourself — do not just jump to the solution. Really try to figure out a possible solution before looking it up. Also question things, do not just take them at face value.

I often draw parallels between mathematicians and hackers. In my opinion, both are problem solvers and really demonstrate “the hacker’s mentality”. Alain Connes, a French mathematician and Fields medal winner, claimed that one should read mathematics books backwards. The goal being that the reader would encounter theorems and be forced to think about how they could prove that theorem. Personally, I would nearly go as far as saying that hackers should try a similar approach. If you encounter some new technical or security-related problem, ask yourself how you could go about implementing it in practice and then maybe how to misuse it. Ask yourself how could someone else make mistakes while setting up a particular feature or technology when you read documentation and specifications.

How can someone get more involved in the security community, what would be a good first step?

I recommend contributing to open-source projects. This is a great way to meet new people. I find the process to be more rewarding than simply reaching out to random members of the community at first. Your contributions are more likely to be noticed and hackers might be more willing to help you out in return. That being said, do not be afraid to reach out to someone you look up to or want help from. Networking is really important in the security industry.

Besides online networking, consider going to meet-ups and joining local security groups. Meet-ups are a fantastic opportunity to meet people and make new friends.

When you actually hack yourself, what kind of vulnerabilities do you usually look for?

I love this question for one particular reason, it might finally explain to some readers why I sometimes report security vulnerabilities to vulnerability disclosure programs which do not reward hackers with bounties. Whenever I heavily rely on a particular product and the team maintaining the project has a disclosure program, I might find myself testing the product for my own security. So the vulnerabilities that I have reported to projects such as GitLab, Rocket.Chat, and Keybase, for example, come as a result of me hacking myself.

In terms of the exact findings, those tend to be bugs specific to the product I am using. This comes as a result of really knowing the ins and outs of the target because I am an actual user. I think Keybase put this best in one of my reports:

“[…] we applaud the researcher [EdOverflow] for thinking about our product specifically, not just applying a generic checklist.”

In your opinion, what is something that often gets overlooked by bug bounty hunters?

Not sure about how often this is overlooked, but I would like to remind readers and fellow hackers of how important it is to balance hacking with a healthy lifestyle — mentally and physically. I know from experience how easy it is to overlook healthy habits when you are completely invested in security. Try to remember to take regular breaks and even consider finding other interests and activities outside of security to keep you going so that you do not get overwhelmed by everything security.

Finally, you are also a member of Disposable mail Crowdsource. From your perspective, what is the biggest benefit of that approach compared to traditional bug bounty-programs?

Disposable mail Crowdsource has been especially useful for me to earn money with previously-disclosed vulnerabilities and some interesting techniques that I have been holding on to over the years. Knowing that my findings could still benefit Disposable mail clients out there and are not completely used up is extremely encouraging.

I also like the 0-day disclosure assistance that Disposable mail offers. Not only am I able to reach out to the right people concerning my findings, I am still able to earn money from those findings.

Find out more about EdOverflow:

Twitter: @EdOverflow
https://edoverflow.com/

Are you interested in joining EdOverflow and other security researchers on Disposable mail Crowdsource? Email the Crowdsource team at [email protected] or learn more on the blog.


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the Hacker: Inti De Ceukelaire – “While everyone is looking for XSS I am just reading the docs.” – 10 minute mail

Inti was recently speaking at Disposable mail 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.

A photo of ethical hacker Inti de Ceukelaire 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.

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 Disposable mail could have found? So I would definitely go with something like Disposable mail 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. Disposable mail 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 Disposable mail.

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.

 

 

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.

 

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, Disposable mail 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 Disposable mail 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 Disposable mail Hacker School. How did you actually get in contact with Disposable mail?

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

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


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.