Rendition’s “Bug Bounty” Story

If you’ve been coming to the Rendition website for a while, you’ve probably noticed that our website has been getting a face lift.  As part of that face lift, we moved the site to a new server and in the new Apache server configuration, we forgot to include custom error handlers.  Today, we got a report from a researcher that our site was vulnerable to “HTML Content Injection.”  You’ll note that we don’t have a disclosure policy on our site.  We’ll change this to ensure there is no confusion about what we do and don’t consider okay.

We examined the report and noted that what the “researcher” was calling “HTML content injection” was actually a default 404 error page.  This allows a potential attacker to display arbitrary text (and only text) on a 404 page.  The attacker could put a URL or an email into the page, but neither of these would be clickable as a link.  In any case, it would require a victim to copy and paste a link or an email address.  There is no opportunity for code execution.

An example request would be “GET /%20,%20and%20about%20Renditioninfosec%20service”

This shows the victim an email of and a site of  When we find these on penetration tests, we rate them as informational since there is no opportunity for code execution and no link to click.  In other words, the victim would have to be confused by the text and then copy and paste a URL or email to be “exploited.”  In researching the bounties paid to others, we see that multiple sites do not pay at all for this and other sites have debated if and what they will pay.  There does however seem to be a consensus that if this is a vulnerability at all, it is simply informational.

As we received the email notifying us of the vulnerability and requesting payment (for a non-existent bug bounty), we noted that our site was slow to respond.  We found that the attacker had performed more than 37,000 requests to the site in a very short period and was continuing to pound the site with requests ranging from directory traversal to SQL injection and XSS.  We blocked the IP address (understanding of course how fragile IP blocks are) and continued on. Of course we see attacks regularly, but not in the volume that this individual was performing.  We notified the individual that we did not condone the attack of  our site and the near denial of service condition that he was imposing.  At this point, the individual seemed to be trying to shake us down for a payment over email, a serious ethical issue.

After some serious consideration, we have decided against posting the email address of the individual who attacked our website.  After researching the IP address where the attacks came from ( and finding no information, we have decided to post it here so that others can block and/or detect attacks coming from this IP address.