Editor's Note: Bugcrowd community researcher, Duarte Silva, shares the story behind how he started working in information security. Duarte is one of Bugcrowd's top researchers, you can follow him on Twitter at @serializingme.
About the Author: Ben Sadeghipour has been participating in bug bounty programs since February of 2014. After his first few bugs, he came to realize that bug bounties are a great way to learn more about web application security as well as make some extra money while going to school - computer science major. Currently Ben is an intern at Bugcrowd and continues to do bug bounty research. You can see more of his work on nahamsec.com.
[Today I’d like to introduce you to Bugcrowd member Ciaran McNally. (maK0) As a freelance security consultant as well as entrepreneur, Ciaran has helped improve the security of many organizations. We are honored to share is thoughts and experience on how organizations can increase their overall security. Thanks!
This post originally appeared on Tripwire.
[Today I'd like to introduce you to Bugcrowd member Satish Bommisetty. An author and professional security researcher, Satish has helped improve the application security of dozens of companies by reporting over 170 valid vulnerabilities through Bugcrowd. We are honored to share his thoughts on how bounty hunters can deliver high quality professional results and create a respectful security research community. These are things that help form a researcher's positive reputation among peers as well as with customers.
[Bugcrowd is a proud sponsor of Nullcon 2015, which is less than a week away! While we are putting the finishing touches on our Bug Bash event, we want to introduce you to another of our outstanding Crowd members in India that will be on the ground helping all the Nullcon Bug Bash participants to have a great experience.
[Bugcrowd is a proud sponsor of Nullcon 2015, which is rapidly approaching! While we are hard at work preparing to host an awesome Bug Bash event, we want to introduce you to a few of our outstanding Crowd members in India that will be on the ground helping all the Nullcon Bug Bash participants to have a great experience.
[The Shmoocon presentations I recommended last week did not disappoint, and I'm excited to have the opportunity to share some of the great research I saw there with Bugcrowd customers and Crowd members. This tool released by Justin Kennedy and Steve Breen can be used by both Red Teams and Blue Teams. Enjoy! ~Kymberlee]
Guest Blog: httpscreenshot - A Tool for Both Teams
Shmoocon is one of those few security conferences that has been around for quite some time, each year selling out of tickets in record timing, and only allowing those with the quickest mouse clicks to obtain them. Luckily for Steve Breen and me, we had the privilege of giving our talk “httpscreenshot – A Tool for Both Teams” this year at Shmoocon, securing tickets for ourselves.
The reason that we named this talk “A Tool for Both Teams” was we believe that both red teams and blue teams can benefit from using it just the same. I’ve been on both teams myself, defending networks, as well as breaking into them, so I feel justified in talking about the problems faced on both.
On the blue team, the biggest problem we’re trying to solve is for networks and systems administrators not having a good idea what is sitting on their networks. On the red team, every single network we are targeting (and in turn, supposed to be assessing) is an unknown to us, and we don’t always have a lot of time to explore it. Our solution to these two problems is httpscreenshot.
httpscreenshot is a set of two python scripts (httpscreenshot and cluster) developed internally over the past two years that takes screenshots of websites quickly and reliably. The cluster script then perform “fuzzy matching” on the HTML output of the pages to produce an immediately usable output with “similar” pages grouped together.
What we believe sets httpscreenshot apart from other similar tools out there are the amount of features that we’ve put into it, but keeping the tool fast and thorough. Here is a quick list of the features of the tool:
- Has the ability to parse gnmap output from nmap and masscan
- Performs autodetection of SSL if version scans weren’t run
- Scrapes SSL certificates for domain names and alt names to add to the queue (no more missing vhosts due to hitting by IP address)
- Runs headless or configurable fail-over to FireFox so you can use your favorite remote server easily
- Threaded, so it’s pretty quick
- Saves output of websites to both PNG and HTML so you can easily grep the source if you’re looking for something specific
One of the few ways that I’ve leveraged this tool myself has been on bug bounties. For any bounties out there that allow for fairly open scope such as Facebook, Google, eBay, etc…. this tool is a fantastic way to quickly uncover attack surface (as demonstrated in the demo at the end of this post). Just a few weeks ago Ryan Dewhurst (@ethicalhack3r) mention that he found Jenkins on one of Facebook’s acquisitions on a non-standard, netting him some fairly easy cash. I found the same on eBay, and the cluster portion of httpscreenshot put them all together for me for multiple submissions. :)
If you find the tool useful, want to provide some feedback, or need any help with it, just reach out to @breenmachine or me (@jstnkndy) on Twitter, IRC (breenmachine or juken), or raise an issue on github (github.com/breenmachine/httpscreenshot). If you want to see the tool in action, check out the demo below or go play with it yourself!
Justin Kennedy (@jstnkndy) is a Principal Security Consultant at NTT Com Security and currently leads the Offensive Security team there. His expertise lies in social engineering, physical security, and other areas of penetration testing and offensive security. Justin's background includes systems administration, network defense, and being mischievous. When he's not popping boxes and rolling networks, you can often find him being a coffee and beer snob.
Recently Geekspeed discussed the importance of well written repro
steps when he shared his tips on writing a great vulnerability submission.
Digging deeper into that, I'd like to reference a great blogpost by
Planet Zuda on Writing a Proof of Concept For Security Holes. ~Kymberlee
[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.