This is a write-up on the Fastest Fix on Open Bug Bounty (OBB) Platform. The security team was extremely prompt in responding and fixing the bug.
I don’t usually write articles related to the bugs that I have reported to organisations through responsible disclosure, however, I have gotten explicit permission from Kevag Telekom GmbH to write a blog post about this report.
Fastest Fix Achievement Badge
To achieve “Fastest Fix” on Open Bug Bounty, it is compulsory to complete all the following within 24 hours:
- Reporting a bug through the Open Bug Bounty platform (link)
- Contacting the affected organisation (via Twitter, Email, Contact form, etc.)
- Providing a Proof of Concept (POC) to demonstrate the vulnerability
- Getting the organisation to fix the vulnerability and deploy it to the production environment
- Conducting a regression test to verify that the vulnerability has been fixed
- Triggering Open Bug Bounty platform to verify the fix and update its tracking status
After successfully completing the above steps within 24 hours, the following simple badge has been earned:
Open Bug Bounty Platform
A short introduction of the Open Bug Bounty platform for folks who are unfamiliar with it:
Open Bug Bounty is a platform that performs independent verification of the submitted vulnerabilities to confirm their existence as a third party. It also provides proper notifications to website owners by all available means. For example, sending notifications to a list of common email addresses, such as webmaster[at]example[dot]com or security[at]example[dot]com.
Non-intrusive Testing Only
Due to the nature of this platform, security researchers are not explicitly given any permissions to perform any forms of testing on these organisations’ web assets. As such, the platform has been constantly reminding the researchers that they should only use non-intrusive testing techniques.
In terms of bugs category, only non-intrusive vulnerabilities such as Cross-Site Scripting (XSS), Open Redirect and a few others are accepted on this platform. Intrusive vulnerabilities like SQL Injection are not accepted.
It is extremely important to remember to not run any vulnerability scanner or automated testing on websites without permissions.
Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) on Login Form
The reported bug was a simple XSS vulnerability which exploited the fact that the Login form would reflect any submitted value back onto the page and also, the fact that there is no anti-CSRF token being implemented.
Fair enough, a login form by itself would usually not require any anti-CSRF token as there will not be any security risk, however, because of this, I was able to craft a CSRF proof of concept HTML page which would automatically submit a maliciously crafted HTTP POST request on behalf of the user who visits the page.
The following is the vulnerable HTTP POST request that was shared with the triage team:
POST / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept-Encoding: gzip, deflate
The following is a simple POC which I have also shared with the triage team, it is an HTML page that would automatically submit an HTTP POST request when the user visits it.
<html> <body onload="document.poc.submit()"> history.pushState('', '', '/') <form action="https://kundencenter.kevag-telekom.de/" method="POST" name=poc> <input type="hidden" name="username" value=""><svg/onload="alert(document.domain)">" /> <input type="hidden" name="password" value="test" /> <input type="hidden" name="IDoMNJOiN6VTxald" value="CzFKivJzOP5Os6t1" /> </form> </body> </html>
Why is this awesome?
No, the XSS vulnerability is not awesome.
The speed and accuracy which Kevag Telekom GmbH responded to my report and triaged the vulnerability (scroll up and read step 1 to 6 again) — THAT was awesome!
I have worked with over 50 organisations with and without Hall of Fame listings and worked with their triage team to fix security vulnerabilities before, only a handful has responded with such speed and accuracy. By accuracy, I mean those that fix the issues effectively.
The more amazing thing is that the person who worked with me to fix the issues on Kevag Telekom GmbH told me that he has never heard of the Open Bug Bounty platform before our conversation. At the end of the day, he also provided feedback to me that he found that Open Bug Bounty is a great platform. He liked my report and the overall working experience was great.
Can you imagine someone who does not know about this platform, get notified by it, reacted quickly and positively when I contacted him about this report, worked with me and resolved the issue effectively, then deployed it after proper internal testing? Large organisations usually have many processes and will not fix issues this quick — FYI, they are a telecommunication company, which means that they are not a small organisation either.
Key things to take note of before participation
If you are keen to participate on this platform, please take note of the following message from the Open Bug Bounty administrator (link):
We encourage website owners to say at least a “thank you” to the researcher or write a brief recommendation in the researcher’s profile. There is, however, absolutely no obligation or duty to express a gratitude in any manner.
So, please do not blackmail the website owners, as there is no obligations to provide any bounty. Some websites might write you a recommendation, such as the following which I have received from Kevag Telekom GmbH, the 5th Dunstable Scout Group and the University of Otago.
Disclaimer – this post is not affiliated with OpenBugBounty, Kevag Telekom GmbH or any possible parties. It is solely based on my personal experiences using the platform and interacting with any of the mentioned organisations.