Security Engineers by Day, Hackers by Night – An Interview with Two of Singapore’s Top Ethical Hackers

I love the diversity of talent on display each and every day within the HackerOne community. We have thousands upon thousands of hackers from all over the globe with diverse backgrounds and unique life experiences. This recipe is the magic of hacker-powered security. 

This post focuses on those who are hackers by night and defenders by day.

I spoke to two such hackers in a recent HackerOne webinar. Kaung Htet Aung (@ris) and Samuel Eng (@samengmg). Both can be found in Singapore, hacking part time while holding full time jobs as part of security teams at leading tech companies. 

From my experience talking to hundreds of hackers over the years, those who hack 9 - 5 in their day jobs and moonlight after hours as bug bounty hunters all tell me the same thing: bug bounty hunting makes them a better security engineer and their work as a security engineer makes them a better bug bounty hunter. 

Check out some highlights of our discussion including those “top of mind” questions both hackers and organizations have about each other, tips and tricks on hacking, and how hackers can collaborate with security teams more effectively. 

Q: Please introduce yourselves! Tell us who you are, what you do, and what your handle on HackerOne is!

Kaung: I’m Kaung Htet Aung, and my handle on HackerOne is @ris, so people call me Ris all the time! I’m originally from Myanmar, but I’ve been living in Singapore for about 12 years now. I’m also a Security Engineer at Gitlab, so that’s my full-time job, and I am doing bug bounty part-time.  

Samuel: My name is Samuel, and I am from Singapore! My handle on HackerOne is @samengmg, which actually represents my full name. I work as a Security Engineer in ByteDance, and I do bug bounties as a hobby. I started on bug bounty in November 2017 on HackerOne! 

Q: Please share with the audience, how did you discover hacking? When did you start hacking?

Kaung: I started hacking after high school, but, at that time, I didn’t know what hacking was or what it meant to be a hacker. At that point, I was just interested in computers, I just wanted to know things like how a hard disk or floppy disk worked, things like that. At that time, the internet was very limited as well. I used to buy a few prepaid internet cards to go online for 1 to 2 hours. Then, I chanced upon a few interesting forums that talked about tricks we could do and a few tutorials as well. I downloaded them into my USB/ hard disk to read, and that’s how I started. Professionally, I think I started hacking 8 years ago during my time as an undergrad student.

Samuel: Well, my story is kind of different! I started in my university days as a developer. Well you know as a student, grades matter a lot! So, one day, one of my professors actually told me that my code was full of bugs, and I would need to fix that to score an A. I said, ‘but it’s working right?’ My professor taught security, and he told me ‘it’s not application bugs, it’s like security bugs!’ And being the good student I am, I decided to look into security. Eventually, I got hooked onto it, and I started going into certifications, and eventually moved onto bug bounties on HackerOne!

Q: Both of you know what it’s like from the offensive side as a hacker, submitting a bug, writing a beautiful report. However, you guys are also on the blue team side, receiving reports from hackers like yourself, because of your full-time job. Can you share how hackers should  interact with security teams effectively? What does a good interaction look like?

Kaung: I get excited when I receive a good report submission from the hacker community! A good report to me, has very clear remediation steps, and shares the security impact. Sometimes, a good report doesn't have to be a long one, it can be as short as the steps I, as a security engineer, need to do, and a clear example that shows the impact of the vulnerability, and what the maximum impact the vulnerability can cause to the organisation.

As a hacker, when I see a good report, I try to reproduce it, and I go beyond. I want to see what the root cause is, as I hate deploying temporary fixes everywhere. I want it to be fixed; and as a universal fix. In reality, this is not always possible. Whenever there is a flaw, security teams need to patch it quickly whenever possible, and then we can investigate further to find the root cause and fix the flaw. So it takes time! 

As part of the internal security team, we can take the report and further dig into our systems to see if there are alternative ways to exploit the vulnerability, and even go further with it to access the most critical finding of the entire report.

Samuel: As a hacker, I always strive to provide easy-to-reproduce steps and a good proof-of-concept (POC). Coming from the blue team side, I love to see reports that make me think of what the attacker wants to accomplish. As a hacker, there are limits to how far you can go with hacking (or exploiting the vulnerability), but internally, the security team will further investigate the report and find out how far the security flaw goes within our network as well as the severity of it. 

Q: What does a good bug bounty program look like to you? What makes a program an exciting target for a hacker? 

Samuel: I think most hackers really like a big scope with big bounties. That includes me as well, as that is a really attractive feature for hackers! Of course, that is not all that matters. As a hacker, I tend to look at the nature of the program from the company as well. For example, I enjoy focusing on the bugs that are specific to their context. If it’s a financial company, I will go after  specific vulnerabilities that are used to target financial data like improper access control, or insecure direct object reference (IDOR). 

Kaung: As part of the security team, I would say a good bounty program for me is dependent on  engagement and visibility. If we have good engagement with the hacker, it’s like an extension to our internal program team. We can communicate clearly and solve ambiguities in the report quickly and easily. 

As a hacker, I think having visibility is another important factor for me. Based on the bugs that were found, I would like to know what steps the organisations are taking to fix it — What is going to be done next? What is the timeline to fix it? How will they fix it? I think responsiveness from the organisation, and two-way communication is important. 

Q: What do you see as the biggest benefit of doing bug bounty for companies vs hiring someone or doing a pen-test? 

Samuel: I think both of them go hand-in-hand. Recently, I’ve noticed that bug bounty programs are really getting popular in the cybersecurity industry. It is like a form of defence in-depth solution. I’ve been on both sides, as a penetration tester and a bug bounty hacker. As a bug bounty hacker, I get the chance to work on many kinds of technologies that span from ASP to GoLang and Rust, so this allows me to better understand how to defend a certain type of attack. In pen-testing, we usually have to stop at a certain point but some programs do allow hackers to escalate our findings further. In this way, it really helps us to improve our skills. In addition, most hackers are very updated with the latest attack methods when it comes to vulnerabilities, and it can be applied to their own workspace. So in that sense, the value of working in a bug bounty program can translate to pen-test and your value to your company also goes up, making you more hireable.

Kaung: I think there are two main differences. The first is payment. For bug bounties, it’s a pay-for-results model — A company will only pay hackers when they receive a valid vulnerability report. Whereas  in pen-testing, companies have to pay for the entire effort. The other point is access points and the level of information made available to the hacker (read more on this here). In bug bounty programs, hackers have access to crowdsourced security knowledge, things like different approaches and methodologies to tackle systems and vulnerabilities. However, in pen-testing, the pen-testers are limited to a limited pool of expertise. 

Q: What would you wish every company knew before starting a bug bounty program? 

Kaung: Before launching a bug bounty program, I think companies need to do their own security assessment. It’s the process of making sure that everything is secure in context, then launching it and having the community of hackers test it, to see if their assumptions of being secure is right. Also, I think companies don’t have to hide things unnecessarily. Giving good visibility to the hackers on the program can be a win-win situation, as long as you are in a reserved environment.

Samuel: To start a bug bounty, I think companies need to have the appropriate technical experts to handle the reports, and not just push the work to the General IT staff. Like what Ris mentioned, a proper security assessment before launching the program is also essential to set the tone of the program. 

I would also suggest not doing self-managed programs, unless the company is already experienced in bug bounties, and have a good team in place to handle the reports. Sometimes, a hacker might not be that proficient in English, or their reports may not be so clear at first look. HackerOne helps to bridge that gap. HackerOne’s Triage Team  is really good at managing the reports, filtering them and providing easy-to-reproduce steps for the internal team, and I have seen that within my own company as well. 

For those who want to hack like Ris and Sam, sign up today and to learn more about HackerOne’s products and services, please reach out today to start a conversation.