Recently we held a GitLab group conversation and AMA/Ask Me Anything with bug bounty hunter and GitLab Hero, Riccardo Padovani (@rpadovani on HackerOne and @rpadovani93 on twitter) about why he hacks, how he hacks and advice for others looking to do the same. That conversation inspired many of the questions in a new series we’re kicking off called, ‘Ask a Hacker’.
If you could ask a bug bounty hunter one question, what would it be? Let us know in the comments!
The art of the hack
Why do you hack?
It's fun, it's challenging, and I learn new things about how systems run and how code is developed. I think this makes me better at my day job.
Why hack on GitLab’s BBP?
GitLab is my only bug bounty target, but not because it is an easy one! I am not a full-time bug hunter: I am a solutions architect, and I love my day job. :-)
Two years ago I found, totally by chance, a security bug on GitLab, and I reported it. It was near the start of the GitLab public bug bounty program and the experience was far from optimal, so I explored other programs. After about six months, by chance, I found an issue on Facebook. My experience with that program was quite pleasant, and they paid me.
After another 6 months passed, GitLab fixed my first issue and paid me for it. It was then that I decided to start looking for security bugs in my free time to have some fun and maybe collect some extra money. I tried finding interesting issues in different programs, but was bored by having to learn how a new website or program worked before being able to start trying to break it. I use GitLab daily for my job, I sometimes contribute to it, and I am a GitLab Hero; so the ramp up to hacking it is short. However, since it is one of the most well-paid and better managed programs on HackerOne, there are many hackers contributing, and indeed in the last 6 months, I’ve noticed it's more challenging to find vulnerabilities than it once was.
What types of vulnerabilities do you most enjoy looking for and finding?
The ones that abuse a well-thought-out functionality, usually ones related to access control. There are some classes of vulnerabilities that are quite well known. We all know they are bad, and a slip in the code (XSS, IDOR, SQL injections) just highlights technical errors. What I prefer is finding a way to access data that I shouldn’t be able to access, exploiting a feature that was planned for something else to access reserved places.
What’s something you would like to see improved in our bug bounty policy or our program in general?
I don’t have many suggestions, I think the bounty policy is well-written and the program well-managed. It would be nice to see some dedicated swag, especially for low-level issues, possibly the option to choose some swag over a very small bounty. For me, $100 doesn’t make a big difference in my life, but I’d love to have a GitLab/Hackerone cup :-) . In addition, maybe instead of offering GitLab self-managed licenses when reporters submit three or more valid findings to the bug bounty program, you offer a choice between this and a gitlab.com license. Of course, I’d leave the choice to the reporter.
In addition, I understand why the GitLab team uses templates to reply to reporters, so all answers are standardized and the team can save time. However, many responses seem very impersonal to me. I’d like to see more personalized communication, rather than just standard reply templates.
Among all the bugs you’ve found, what’s your favorite?
Other than the types mentioned above, I really enjoyed having fun with the Elasticsearch integration last year, it was amazing how much data I was able to leak. I think there are 6 valid reports only about that integration over the course of just one month (see the first report that led to the chain of reports, "Group search leaks private MRs, code, commits", and I think the team hated me a bit for that 👼 .* Also, I found a bug when moving a project from one group to another group which kept properties of the previous group. This would give access to unauthorized users of the second group.
*Editor's note: Not even a little. We ❤️ it when someone responsibly discloses a vulnerability to us!
What advice would you give someone looking to start participating as a researcher in a bug bounty program?
Take note of features that are interesting to you. Keep notes where you can review what you have already done, and what you have already found. This will be useful if you step away and come back to a target. It takes time and it takes luck. Do not leave your day job until you are well on your way, and remember to set aside some money to pay your taxes when they are due!
What’s your favorite security research paper or thought leadership piece?
I recommend reviewing this paper HTTP Desync Attacks: Request Smuggling Reborn report for research on remote, unauthenticated exploits: it is quite interesting since it shows how you can exploit something that is not strictly a bug, but instead different behavior between two systems. This is one of the reasons security should be vertical to the entire development stack, and not just a separated silo. Another good read is this classic, foundational paper, “Reflections on trusting trust” for anyone who is interested in or practicing security. It’s more philosophical than practical, but shows how security is not “on/off”, but is more a compromise between the change of something being exploited, and the price to avoid it being exploited.
Tangential targets
If you use GitLab frequently, what features do you like the most? Where can we improve?
I really like board issues for groups, and the fact that the wiki is a git repository itself. The To-Do List could be improved: you can only add to-dos from some elements. I appreciate that a lot of the devops lifecycle is covered within GitLab and using it helps me enable my colleagues to do their work. I work with many smart folks like Mathematicians and Physicists, and I can automate their workflows using GitLab which is helpful to all of us.
What would you like to see more of in the industry?
A lot less NIH (not invented here) mentality, and a more common approach to things. Computer Science isn't a science yet. We re-build all the same things over and over, always making the same mistakes. Why can we build buildings that stand hundreds of years, but software that cannot run more than 5-10 years (when very well done)?
Big fish, small pond or small fish, big pond?
Small fish, big pond; I like to be challenged.
If you could automate any one thing, what would it be?
Home chores :-D
Have a favorite app?
Bitwarden, it’s useful to store a lot of data (especially passwords!) and just forget about them.
Favorite Linux distro?
Ubuntu
What was the first computer you owned?
Dell Inspiron 6000
Favorite brand of beer, wine, soda, other?
Any of the six sisters of Munich, but a special shout-out goes to Hacker-Pschorr, and not only for the name. ;-)
Have a favorite quote?
Talk is cheap, show me the code. (L. Torvalds)
People will always complain or suggest that they can do better. Well, talking is easy, let’s see if you are as good as you say! It’s also one of the coolest things about well-maintained open-source projects: there is a do-ocracy, where the only thing that matters is your contribution, not who you are or what you say.