Tales from a Bug Bounty

On the 18th of November I submitted a ticket to the Monero HackerOne Bug Bounty program. This is the ticket regarding ‘GarlicRust’, a vulnerability I publicly disclosed in my previous blog post. Unfortunately for me, Monero updated the bounty terms after my submission, and the bottom line is that I did not receive the bounty I initially expected.

Disclaimer: This entire post is presented from my point of view. I am aware of the fact that some people might see things differently.

Monero Bug Bounty

The following sections will describe the chain of events, as experienced by me, that happened during the lifetime of my ticket. First thing first, my ticket (linked here) was opened on the 18th of November.

Monero’s HackerOne Page

On the 29th of November someone edited the page.

Monero’s FFS

The FFS is a forum funding page, opened to raise funds for the bug bounty program of Monero and it’s sub-projects.

Kovri bug bounty

On the 30th of November the kovri project’s policy was updated – link.

Back to the HackerOne ticket

Thinking that the Monero Bug Bounty program in HackerOne agreed to pay 500 XMR minimum bounty, and seeing that (at that point of time) kovri was specifically included in that program, I decided to try my luck and search for vulnerabilities. Although I found ‘GarlicRust’ and submitted it, it seemed that the project was reluctant to pay 500 XMR for it.

The initial response stated mainly that:

  • kovri is pre-alpha
  • The developers wanted to change it’s scope to include only crypto issues
  • The developers said I will get payed nevertheless
  • The developers asked for a “PoC Exploit”

Since I did not want that any mistake of mine will spread through the i2p network, I took precautions while I demonstrated the exploit:

  • I traced the vulnerable code lines in a kovri router that I compiled from sources
  • I modified it’s code to drop the leaked message instead of sending it to the i2p network

I then uploaded the logs and the screenshot from my exploit to the ticket.

From that point, things just got worse:

  • Kovri requested a “code PoC”
  • The developers mentioned that “A scenario (and screenshot) has the potential to be manipulated to fit this control”
  • The developers asked for a git-diff of my attacker script

I went back to my test network to bring up a fully functional isolated i2p network:

  • I built up an i2p network with only 2 nodes – Attacker & Victim
  • The network was isolated from the real i2p network to make sure the exploit won’t harm anyone in the real network
  • I added debug traces to the victim kovri router in order to show that the vulnerability was triggered
  • I modified another kovri router that will act as my attacker
  • Both routers were modified so that a tunnel could use the same router multiple times – allowing a small network to be established

And indeed, I demonstrated the exploit in this test network (the exploit’s logs were added to the public disclosure post). To make sure that this time my submission would suffice, I wrapped up and submitted my entire test setup:

  • Full src & binaries of the victim router
  • Full configurations & logs of the victim router
  • Full src & binaries of the attacker router
  • Full configurations & logs of the attacker router
  • A detailed README that describes the setup, the attack flow, and anything I though relevant

Unfortunately, the submission was pointless as kovri refused to check my PoC. In addition, on the 2nd of December, I received a reply stating that:

In fact, nowhere in our policy or VRP does it state that any pre-Alpha kovri bug will receive any XMR. This is because we’ve only recently started using HackerOne and had yet to finish working out the details. Please review those details for future bug bounty payout.

Needless to say that on the 2nd of December the references where already updated, stating that kovri is not eligible for any bounty.


The hackerOne ticket is now public (on the demand of the Monero project) and closed. The vulnerability is classified as “high”, although it’s title was changed so that the vulnerability will be marked as “potential”.

The bottom line: Monero offered to pay 1 XMR for my vulnerability. Overall, the program’s FFS states that they never given out even a single XMR to any researcher: 0/1275.

While I wanted to focus on the impact of the ‘GarlicRust’ vulnerability, it is sad that I now have to focus on the bounty instead. Reluctantly, I encourage other security researchers to learn from my mistakes.


Author: eyalitkin

White hat security researcher. Recently finished my M.s.c at TAU, and now focus on security research, mainly in open sources.

4 thoughts on “Tales from a Bug Bounty”

  1. Due to technical errors, a comment from Riccardo Spagni (getmonero.org) was dropped. And so I repost it as it was written:

    Hi! Thanks for the blog post. As an open-source project with no central point of authority it is difficult to produce perfect “policies” from the get-go. Something like the VRP requires ongoing effort. We’re also aware that security researchers are external and may not be aware of discussions that happen in the Monero community.
    Thus, your discussion with the vulnerability response team triggered some clarifications in the VRP. These were not done to screw anyone over, but rather to clarify publicly what we knew internally. As an example: it would be unconscionable and irresponsible of us to award a 500 XMR bounty to an extremely hard to trigger CSRF “vulnerability” if the RPC interface’s authentication is forcefully disabled. But despite the difficulty in something like that ever being exploited, a researcher uncovering that could still receive a small bounty.
    I apologise deeply if the impression was ever created that the bounty was 500 XMR, that was merely the minimum we sought to crowdfund, not the minimum we sought to reward researchers with. I also apologise that you’ve had a difficult time disclosing this, and that an impression was created that we changed the rules. The good news is that this interaction has allowed us to clarify the VRP so that there are no problems in future.


    1. First of all I want to thank you for the detailed response, and I assure you that I would have acted differently if this was the initial response from your staff. However, your representative did little to verify the vulnerability or the PoC, and together with the phrasing of the responses and the statements that kovri never mentioned a bounty, it was easy to get a bad impression regarding the overall submission process.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: