GitLab is best known as a complete open source DevOps platform, delivered as a single application, but it also offers powerful project management and collaboration capabilities. In fact, every GitLab team uses GitLab to develop, track and collaborate on projects, processes, and programs.
But, what about... other uses? Say ... hacking, for instance. 🤷♀️
Can GitLab help a hacker fine-tune their craft? Through our Ask a Hacker AMA series we discovered that there are some bug bounty hunters who use GitLab to streamline their research process. And, like so many cool and awesome things, we learned on Twitter about another contributor using GitLab for bug bounty hunting. So, we followed up to learn more.
Meet our hackers
Alex Chapman
Alex has been hacking for 14 years professionally, but his interest was piqued well before that!
🦊 @ajxchapman on GitLab 🪲 @ajxchapman on HackerOne 🐦 @ajxchapman on Twitter
Dominic Couture
Dominic is a senior security engineer on GitLab's Application Security team and has been hacking for fun for roughly 20 years, though he admits there were some "long periods in the middle where he didn't do too much". 😆
🦊 @dcouture on GitLab 🪲 @dcouture on HackerOne when working and dee-see on HackerOne when playing! 🐦 dee__see on Twitter
Nishant Jain
Nishant has been hacking for 1.5 years and is currently working on LinkShare, a platform which enables users to share and categorize bug bounty resources. 🦊 @archerl on GitLab 🪲 @archerl on HackerOne 🐦 @realArcherL on Twitter
How do you use GitLab in your hack?
Alex: I use GitLab for all of my bug bounty issue tracking from idea, through discovery, POC development and report writing. One of the biggest revelations for me in bug hunting involved note-taking. I used to be terrible at recording my thoughts, progress and ideas when hunting for bugs. This meant whenever I got sidetracked, or took a break, I would inevitably forget what I was up to and what leads I was working on.
Now I record everything I can in GitLab issues. Have a random thought about something to check? Create an issue for it. Spot a potentially interesting bit of functionality while pursuing another bug? Create an issue. Get inspiration in the shower? That's right, get out the shower and create an issue. Even if I don't think it's particularly useful at the time, it can sometimes spark something several days later and I can go back and find those notes. I tag each issue with a label specifying what kind of issue it is (bug, task, lead, etc.), how worthwhile I feel it will be to complete, and how much effort I think it will require. This way when I complete my current bug exploration path, I have a whole load of leads I can go back to and pick from and investigate.
At the end of each bug hunting session, I always make sure I take five to ten minutes to write down any outstanding thoughts so nothing is lost between bug hunting sessions. This way of working means I always have a pipeline of things to investigate and, when I wake up in the middle of the night with a new idea on how to exploit something, I can just add to the existing issue and push it off until morning. Whereas before, I might have got up and started working on it right away. That's not really viable for me these days, I'm certainly getting older and I need my sleep 🤣
As an issue progresses from a lead to a reported bug, I label the issue with the bug bounty program report state, and finally as bugs are paid out I label the issue with the payout amount. This helps track lucrative programs and functionality for future research.
Editor's note: To dive even deeper into how Alex approaches bug hunting, check out his "Ask a Hacker" profile blog and this Ask Me Anything session we held with him where he talks about everything from what inspired him to start hacking to the types of bugs he likes to hunt.
Dominic: I use GitLab private projects to collaborate with friends on hacking projects. Our approach is simple: Each idea about a potentially interesting thing to explore gets its own issue and then we discuss, via comment thread, the different attack vectors and the things we try and whether our attempts work or not. Everything is documented with screenshots or code snippets using the markdown formatting. When we find something it's reported and a ~reported label will be applied. The issue is closed either when a reported issue is accepted by the bug bounty program or when we've finished exploring an idea and found nothing. This helps us collect all ideas, validate them and exhaust all possibilities we can think of before moving on.
The other useful part is obviously the git repository. Any script that we come up with, any important file that was found, or any general note that isn't related to one specific issue is pushed to make sure it isn't forgotten over time. I have a handful of interesting targets that I like to focus on for a month or two in rotation so I can give them my full attention and go deep. This means that a given target will usually be focused on once or twice a year with long downtimes in between. The repository contains all the things I'll definitely forget and will help bring me back up to speed when the time comes.
Nishant: Like all great things, we stumbled upon our next contributor's story via the internet. Twitter to be exact. 😉
I've been using GitLab for my blog, where I post details about bug bounties, and the CI/CD feature is really easy to use. I chose GitLab to host my CTFs and hacking POCs because GitLab has shown that it is friendly to hackers (Kali Linux is even hosted on GitLab) and with the Web IDE, I can edit them from the repository itself.
Recently, I've been using GitLab to work with other hackers on HackerOne programs. With HackerOne's bounty splitting feature enabled, two hackers can easily collaborate on a single report. In GitLab, you can construct a group and then add repositories to it. You should give each repository a name that corresponds to the individual HackerOne program.
Creating repositories for different H1 programs
You can create issues in the issues tab, just like a developer, and mark them with custom labels. Not only that, but you can delegate the problem to a collaborator, who will be notified via email – convenient if the hackers are in different time zones. Furthermore, features such as group permission settings allow for the introduction of additional hackers with/without limited access.
Creating issues with custom labels
Also, GitLab provides easy tracking of issues with issue boards. The board function makes it simple to keep track of reports, like which ones are in the triage stage and which ones have been marked as informative or closed. Also, if a similar error occurs in the future, we can still cross-reference it, much as we do when creating real apps. Boards are a newer discovery for me, so I still need to do more exploring here.
Easy tracking of of issues with issue boards
What should we improve so you can hack better?
Alex: I write in markdown, a lot. Unfortunately I find that GitLab is not very friendly with writing or editing large markdown documents in repos, wikis, or issues. My writing style means I make multiple edits to issues or wiki pages, and having to scroll through a wall of markdown source to edit a detail halfway through a page is particularly painful. It would be great to see markdown editing become first class in GitLab, or at the very least let me edit only a code block or text under a heading like on Wikipedia.
Editor's note: good news! We have some really big plans for making markdown editing easier across GitLab. You can check out and follow this epic for implementing a new editor in Wiki and review our strategy for the new WYSIWYG markdown editor to see what's in store.
Dominic: I often have good hacking ideas in random places, whether it's in the middle of the fruit aisle at the grocery store or on a run with my dogs, and when that happens I note those ideas in my GitLab project on my phone. The mobile experience isn't the best both in terms of page layout and performance, so improving that would be awesome.
I think some of my biggest layout pet peeves could be easy fixes, so I plan on working on that myself because, although my frontend skills leave a lot to be desired, everyone can contribute!
Nishant:
Create and select different templates for greater efficiency
I'm not sure if a feature like this exists, but if we could build out custom templates while creating a file, that would save a lot of time when making similar reports.
Editor's note: We have templates for issues and merge request descriptions. Perhaps those help?
Nishant: I see, I think the issues template solves the problem then. 🙌
Also, Discord hooks integration.
Editor's note: We've got a Discord webhook integration. Would that work?
Nishant: Nice! I missed this! I don't think there's much that I can think of now to improve GitLab, although as I noted above, I'd love for there to be more backward integration or compatibility with the markdown in HackerOne and GitHub platforms.
What GitLab feature helps you the most in your hack?
Alex: As mentioned above, GitLab issue tracking is my main use for GitLab in my bug hunting efforts, but I really like that I can link to code and POCs in a repository and keep longer-term notes in a Wiki. I rely on the project sub-grouping features to keep the various bug bounty programs and scope items I am working on organized and tidy.
I have found this setup works particularly well when collaborating with other bug hunters. I simply create a shared project and we can all add to and update the issues, files, and wikis collaboratively. This is much nicer than just relying on Slack or Google Docs for collaboration, it helps keep things more organized and much easier to find than constantly searching through Slack logs.
Dominic: GitLab issues and all the management tools around them is where I get the most value. They help me track all ideas that could potentially become a vulnerability, and make collaboration and sharing easy. GitLab labels allow me to quickly glance at the main issues page and see the state of each issue.
Contributing to this post has made me reflect on how I could get even more out of GitLab in my bug bounty hunting efforts and using issue weights to estimate the amount of work needed to investigate each idea and milestones to plan the ideas I want to cover in a specific hacking session could be good improvements to my workflow.
Nishant: I appreciate that users can make flowcharts and templates with the powerful GitLab markdown (not all features are supported in HackerOne's markdown though, so perhaps adding that capability is a feature suggestion!). I also make use of custom features like customs tabs, boards, lists, etc. Not to mention the fantastic documentation for all the features.
How does GitLab help you hack?
Are you using GitLab in your hack, either to track ideas to bounty or to collaborate on a global scale with other hackers from across the world, or maybe to keep track of all the bits in between? We'd love to hear about it! Tweet us at @gitlab or comment below!
Have a question you'd ask a hacker?
If you want to dive even deeper into the mind of a hacker, join our upcoming Ask a Hacker AMA with William Bowling, @vakzz on June 16, 2021 at 23:00 UTC (see this world clock for conversion to your timezone). Get all of the event details and sign up.
