Hacking the Bugcrowd - Core Researcher scores in Main Program Site

Hacking the Bugcrowd - Evading the Filter Validation of Bugcrowd

Today we would like to talk about a vulnerability that was located in the main bugcrowd web-application. Normally we do hack in regular and public bug bounty programs, but in case of the issue we exploited the manufacturers official program site web-application to score.

The history of the issue begins about 1 year ago in 2015 Q2. We discovered in one of the main registration formulars of the portal an application-side vulnerability. The bug was located in the basic researcher feedback formular of the webpage. After discovering the issue we reported the bug to the bugcrowd community. Some days later we received the reply that the team was not able to reproduce the vulnerability. We tried to explain the impact of the vulnerability but we had the feeling that the ticket manager of the portal was not able to understand the bug at all. Normally we decide to leave an issue to not waste our time in such an inexperienced answers by "security experts".

Vulnerable Module(s): https://blog.bugcrowd.com/increased-pen-test-results-instructure-flex/

At that point we decided to trick the managers into a physical export/import trap to get the bug finally validated by the program. After the ticket was closed, we were watching in the web-portal of bugcrowd for another point to attack with the same typ of conditions. Some time later we have detected another formular that allows to interact with the same conditions.

Vulnerable Module(s): https://blog.bugcrowd.com/[NEW BC EVENT]/register

First you have to know that the data of the registration entry is saved to a database management system. After the save to the database management system the internal exployees of bc trade and copy the list to other clients. Means after a payload is integrated to the dbms the encoding saves the data as plain text format. On the back-implementation to the email service, the firstname/lastname parameters can execute persistent on the application-side because of a wrong parse.

To trap the administrator and to exploit the issue we was patient for the next event, were the formular will be integrated for a specific time period to the bc website portal for the followup mailings. One day in the morning they setup the registration back to the website and we jumped into the exploitation of the function directly. We injected again non-malicious script code payloads to the firstname and lastname input field, with the blind background knowledge of the import/export issue mentioned above. After saving the context via POST method request, we had to wait for some days since the registration confirm arrives via client with the name parameter as payload.

About one week later we received a service mail by the administrator of the bugcrowd portal ceo "Casey Ellis". In the email was visible that the main administrator and ceo of the company ran into our little import/export validation trap. The payload that was injected to the name parameters was replied by the main sender community@bugcrowd.com to the specific register accounts. In the email the regular encoded username was executable streamed in html format. Thus allows the payload to execute within the email message body context without secure validation approval.

Finally you can see in the screenshot above were the code executes and that it was send by the administrators program to the separate user accounts. The code example below demonstrates were the payload was executed against the user accounts.

<table class="templateColumnWrapper" style="-webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; mso-table-lspace:0pt; mso-table-rspace:0pt; border-collapse:collapse !important" border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody><tr><td colspan="12" class="column" style="-webkit-text-size-adjust:100%; -ms-text-size-adjust:100%; mso-table-lspace:0pt; mso-table-rspace:0pt; text-align:left; font-family:sans-serif; font-size:15px; line-height:1.5em; color:#515151" align="left" valign="top" width="100.0%">
<div class="widget-span widget-type-email_body " style="" data-widget-type="email_body"> <div id="hs_cos_wrapper_hs_email_body" class="hs_cos_wrapper hs_cos_wrapper_widget hs_cos_wrapper_type_rich_text" style="color: inherit; font-size: inherit; line-height: inherit;" data-hs-cos-general-type="widget" data-hs-cos-type="rich_text"><p style="margin-bottom: 1em; -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%">Hi&nbsp;"&gt;  <iframe src="a" onload="alert(&quot;PENTEST&quot;)" <="" "="">&amp;lt;iframe src=a onload=alert("PENTEST") &amp;lt;,&amp;lt;/p&amp;gt;  

We reported the application-side vulnerability again a second time to the bugcrowd security team with clear acknowledgment of the already reported issue of 1 year ago.  All thus happened after we triggered the issue with a more obviously valid interaction to make them aware. The report send 1 year ago was denied because the manager team of bc was not able to identify the vulnerability impact. After the new bug  in 2016 was tracked we received an ID of the portal. (b40f63ed19074014df808599e44684f6a18bb6f4f51cf21948ef78df2f56c13b)

The title of the new reported vulnerability was as follows ...  "Bugcrowd Online Service Web Application - (Casey Ellis) Persistent Script Code Injection & Mail Encoding Vulnerability. 1 hour after the report was send to the manufacturer, we got a reply by a german bugcrowd manager, who was processing the reproduce. Some days later the persistent vulnerability was finally confirmed with the full impact and we received a bug bounty reward of 600 USD.

The final exploitation of the vulnerability requires the background knowledge of the services that are used by the internal bugcrowd manager or administrator team. We used reverse engineering and a marketo zero-day issue to identify the used way of communication with interaction by the portal community.

Sometimes manufacturers of bug bounty programs are not able to reproduce an issue or vulnerability by own experience, so you have to help them on special cases with a little trap to score successfully. Do never forget to say thanks after successful exploitation for the next upcoming trap in case of emergency.

Reference(s):

http://www.vulnerability-lab.com/get_content.php?id=1830