[note: Happy New Year Bugcrowd researchers! Once you’ve read the
Submission Accomplished blogpost for vulnerability reporting 101, this
guest blogpost is recommended reading to help you write effective
reports on the vulnerabilities you find. ~Kymberlee]
by: John Stauffacher
No lie, it took me eight nine tries to write this blog post. I offered to write a guest post about communicating vulnerabilities effectively to customers in December, but then faced writer’s block. I’m a professional security consultant and bug bounty hunter and spend a lot of time writing vuln reports, so you would think that writing how to do something I do every day would have been easier!
The more I wrote, the more ironic it got. I’m supposed to be writing a piece on how to succinctly develop quality submission reports, yet I hit 600 words and had not really gotten to the point. I will save you the long-winded diatribe, and summarize it in some bullet points:
Understand Your Audience: Probably the single most important thing to remember when writing a bug submission is that somebody is going to have to read it, and then act on it. Creating a submission that is clear, purposeful, and comes to a clear and actionable conclusion is paramount to a successful submission. The developer that reads your vulnerability report may not be a security engineer. And even if they are, they aren’t in your head reading your thoughts on the risk the vulnerability creates. Make it easy for the reader to understand the security impact so they can effectively prioritize it with their other tasks.
Be Clear: Communication that is clear has a better chance of being understood by your audience. This becomes a challenge when faced with subjects that are not complicated themselves. Having to explain a complex series of events that turned a simple RFI to an RCE is not easy itself, and having to distill that down to be understandable by the most junior member of the staff seems an awfully arduous task. But it is critical that we target our communication to those people so we can be assured the risk assessment is understood. Clarity comes not only from word choice and contextual information provided, but also from the formatting you use in your report. I’ve got some suggestions later in this post to show what I mean.
Have a Purpose: Communication without purpose can be frustrating for the recipient. Think of assembling an IKEA bookcase, and not having clear directions. Bug submissions should have a clear stated purpose. Try not to assume that the reader will derive the context from your writing. Try to stay away from passive speech, and stick to strong authoritative statements that present the bug, the risk, and ideally a recommended form of remediation.
Have an Action: Communication should have some action. Your reader should walk away with an idea of what they need to do. In the case of bug submissions this part is key. This is the part where we have identified the issue so well, or reader walks away going “I got this, I know how to fix it”. This also involves effectively communicating the “risk” associated with the bug to the organization. We, as security professionals, need to connect the dots to show our clients the projected impact a given vulnerability can have.
Putting all of this together, I can give some examples to help you write better quality submissions. I will use the Bug Crowd submission form as an example:
Title: This is the first thing that the client sees and really should shine some light on the particular vulnerability you have found. A good title would include the type of bug found, where it was found, and the overall impact. For example “Remote File Inclusion in Resume Upload Form Allows Remote Code Execution”, is a lot better title than “RFI Injection found in app”. You have articulated in the title just exactly what you have found, where you found it, and the reach of the vulnerability.
Bug Type: It is imperative that this portion is correct. For example, if the bug found is an XSS – documenting the distinction between DOM based XSS and Reflected XSS is key to the client understanding the risk of the bug to the organization.
URL: self explanatory, but important to double check. This is where the client is going to be focusing a lot of their time trying to validate your submission.
Replication Steps: It very important that the Replication Steps be very thorough. You have no control over who is going to be reviewing your submission, so you want to arm them with as much information as you can.
o Weak: Visit ‘www.thatsite.com’ and upload a shell, execute the file.
- Visit ‘www.thatsite.com’ in a browser
- Click the “upload image” button
- On the next page, right click on the ‘choose file’ button, and select “inspect element”
- In the window that opens, find the the ‘<input type=file’ line and remove the ‘accept’ attribute altogether
- Click the choose file button
- Select your shell.php file
- Upload your shell
- Visit ‘www.thatsite.com’
- Click on the “upload image” button. The attached screenshot 1 (screenshot1.png) shows the location of the button.
- Right click on the ‘choose file button’ and select ‘inspect element’. The attached screenshot 2 (screenshot2.png) shows the resulting window.
- Navigate to the ‘<input type=file’ line and remove the ‘accept’ attribute. The two attached screenshots (screenshot3.png, screenshot4.png) show before and after shots of the modification.
- Click the “choose file” button, and select your shell.php file. The attached screenshot 5 (screenshot5.png) shows this process, along with the file (shell.php) I used.
- Upload the shell. The shell can now be accessed by [URL]. This shell allows remote control of the server. For example, I was able to take a directory listing of the current working directory. The details can be found in the attached file (details.txt) and is displayed in detail in the attached screenshot 6 (screenshot6.png).
Additional Information: This section is the money maker. This is the part where we get to explain what we have found, and express the impact and inherent risk. It is important to not only be concise, but to explain in a manner that individuals from different areas of the business can understand. It is important at this stage to be clear, but also state the inherent risk that this vulnerability brings to the organization. It is time to start connecting the dots.
o Weak: Server is vulnerable to SQLi due to an outdated version of Drupal.
The host device in question was found to be running a version of Drupal prone to a SQL Injection attack. (CVE-2014-3704, DRUPAL-SA-CORE-2014-005)
This machine appears to be running [Application] [Version] which is running on port 8443. This [Application] [Version] has been proven to allow the enumeration of users (https://www.drupal.org/node/1004778). Due to a design philosophy [Application] developers believe that username enumeration is not in fact a security threat.
Using these two vulnerabilities an attacker can manipulate a given users account:
- Give any arbitrary user admin rights
- Change the password of any arbitrary user
- Insert their own user with admin rights
The attacker would start by enumerating the users. A web request to: http://[site]/admin/views/ajax/autocomplete/user/a produces a json file listing out all of the usernames that start with ‘a’. A subsequent request to http://[site]/user/[username] will give us their numerical user id. Using one of these legitimate accounts and it’s numerical user id, the attacker can then use the SQL Injection vulnerability (CVE-2014-3704) to craft an exploit that changes the users password to something the attacker can control.
An example request for changing the ‘adam’ users password would look like:
POST /login?destination=node HTTP/1.1
Accept-Encoding: gzip, deflate
After the attacker issues the request, the user adam’s password will have been changed to ‘pwnd’. To give that user administrative privilege, a second request would be made (using the numeric user id):
POST /login?destination=node HTTP/1.1
Accept-Encoding: gzip, deflate
name[0;update%20user_roles%20set%20rid%3D3%20where%20uid%3D[numeric user id];#%20%20]=test&name=test&pass=test&form_id=user_login_block&op=Log+in"
The attacker now has compromised a legitimate account and elevated the users privileges to administrator.
The “Additional Information” section is also a good place to include suggestions on how to fix the issue. It is one thing to point out a flaw, another thing entirely to bring a suggestion on how to fix the issue. Try to include code snippets, configuration snippets or even general guidance on where to start with the remediation process. If you assume your audience has no idea that this bug exists, then you can also assume they would be lost on how to fix it. It becomes your job to shepherd, and guide them to the appropriate fix. These steps increase the value of your submission to the client. You are now not just providing a report, but you are sharing knowledge and providing insight. This is the actionable part of this communication; this is the point where you are giving your audience something to do at the conclusion of your submission.
Attachments: Attachments are your friend. If you record your sessions (and you should), attaching the recorded file to the submission report provides illustrative evidence that just can’t be replicated by a form submission. Short of having a recording, frequent screenshots attached to the submission with an explanation of what each represents can go a long way to helping the client understand what you are trying to illustrate.
I know this is a lot to take in, even more so it is a lot to remember when you are trying to hurriedly pump out a submission before the next bounty hunter beats you to it. But the more you practice, the easier it gets – and the more you don’t have to repeat yourself. Executing quality submissions will greatly reduce the amount of “redo” work you will be faced with and can increase your payouts. The client will not be coming back with simple questions, because you will have given them everything they need to know. Your submissions will also be approved quicker, as you have provided everything needed to make an educated decision, without the need for a bunch of follow up questions.
John Stauffacher (@g33kspeed) spends his days working for Accuvant Labs as a Solutions Architect, and nights chasing bounties for various Bug Bounty programs. John has over 15 years of experience in the industry and has spent an equal amount of time on both sides of the desk. As a consultant John has advised and received commendations from top names in the Retail, Energy, and Banking verticals. John has spoken at various Conferences including PumpCon, CircleCityCon, GrrCon, LayerOne, BSidesLA, DerbyCon, ToorCon, as well as several other Enterprise Campuses. John is active in the National Cyber Defense Competition, where he Red Teams for the Western Region. Your government trusts him, so should you. John really doesn’t think that anybody will read down this far, so if you have – thanks. HI Mom.