Making My First 10K by Hacking Open Source Targets

Reflecting on my first 10K I earned through only working on FOSS targets!

As some of my readers might know, I am currently studying IT security in Germany. (Btw I just made it into the next semester! 🥳)

This article is going to be a bit of a meta one. It wan’t to reflect on the first 10k I got and also see where this blog will go in the future (See the last section for that).

I need to make some money during my studies and one day I decided to put my skills to the test with bug bounty hunting. This time I wan’t to focus on my methodologies and tools I used during my most active bug bounty time. In the end I managed to make (exactly) 10K USD, which is about 9K converted to EUR, so a very nice bonus for the studies!

This one wasn’t too hard, there are many available Platforms that offer researchers the ability to get paid for bugs. All of them have nice targets, so don’t overthink it and just pick one! Just to list a few:

Yep, I exclusively picked targets where I can hack on source code. I just didn’t want any black box testing as I find it frustrating. I have a pretty strong source code review setup that I will share in the following. Oh and I filtered for programs that offer monetary reward :). Thats two filters down! I ended up hacking on the following targets:

Here comes the interesting part. I use only a few tools that serve me very well

Neovim

I have made Neovim my best buddy when looking for vulnerabilities in code. I have functions from big IDEs like go to definition, find word under cursor, jump to Bookmark, live grep and treesitter level highlighting without sacrificing performance.

CodeQL

I use CodeQL to hunt for interesting code snippets, not to directly find bugs. For example I have queries to uncover potentially dangerous functions in C that iterate over memory in an unsafe way or code that does a lot of threading ad disk I/O (would you be interested in a post about such CodeQL queries?)

SourceGraph and Cody

Cody is an AI assistant with whom I chat about codebase contents. It won’t magically find bugs for me but it might just help me to understand the codebase a bit better. For example it might tell me where authentication is exactly handled or where a certain callback is used (things you do not easily find with a simple grep search)

Dynamic Analysis Tools

GDB, Burp Suite, you name it. I just wanted to include this section to let you know that I of course also used dynamic analysis as you saw in my last post.

Maybe even more important are the mindset and the methods I had when looking at code. This task can become overwhelming pretty fast but I managed to find bugs in the end

Follow User Input

Yes, you may have heard this already. But I can’t stress it enough. You can’t hack what you can’t reach! For those who don’t know: You can imagine every application as a complex machine reacting to the outside world in some way. Most of the time this outside world is purely the users input and thus the attackers only way of interacting with the system. Following the users input in the codebase means looking explicitly at the parts of a codebase that processes user input and do interesting stuff with it.

Attack Surface Analysis

I conducted a comprehensive analysis of the application’s attack surface before really starting to hack on it,identifying and understanding the potential entry points for attackers. This involved mapping out the various ways an external entity could interact with the system. So I did a top down approach.

Documentation Review

Thoroughly reviewing documentation, including code comments, specifications, and design documents, was integral!! Often, valuable insights and potential issues could be found in these materials. Especially interesting commets are for example TODO comments or long comments explaining complex functionality.

Be Exceptional

This is the most important one. There are so many other researchers looking at the codebase at the same time. You have to set yourself apart from them. Doing something that no one has ever done before will likely yield new bugs.

We are already at the end of this article! I really wan’t to thank everyone who subscribed to this blog!! I didn’t even think that I could reach 100 subscribers with my first article ^^

So for the future I’m planning on doing more bug bounty writeups when I have the time during studies. I also thought about another thing: Creating a course on advanced obfuscation techniques. Coming from malware development and currently taking courses in advanced obfuscation techniques I think I could create a really cool Udemy course and earn a few bucks along the way. What do you think about that? I will have to decide if something like this is worth my time and gauge how to price the course. It would be nice to let me know if you are interested and if yes, what you think would be willing to pay for a 3–6 hour course!

Oh and because we are speaking about financials… You can now also support me with a small donation if you enjoy my content: via a buymeacoffe, thx :3

Alright thats all! Have a great day! :3