A few years ago, Contrast Security launched a private, “invite-only” bug bounty program focused on Contrast Protect. We served up a vulnerable application and then we instrumented it with Contrast Protect. We subsequently invited researchers to enter queries to try and bypass Contrast protection capabilities. This process yielded some interesting new rule sets on the protection side of the Contrast Application Security Platform.
Building on that success, we recently launched a public Contrast Security Bug Bounty program around Contrast TeamServer, the user interface and data analytics engine for the Contrast Application Security Platform.
Setting Up Our Bug Bounty Program for Contrast TeamServer
For our latest bug bounty program, we created a dynamic instance of TeamServer, filled out with fake data and three different user levels—an organizational Admin-level, a normal Admin-level, and a regular Member-level. Each individual researcher has their own unique instance, which is completely unaffected by other people's work.
A researcher can basically do whatever they want in TeamServer—to launch whatever type of application attack they can imagine. This particular aspect is quite unique to the application security industry from a bug bounty program standpoint. It’s probably more of what one would expect from a Software-as-a-Service (SaaS) company—but technically it was difficult to put together and there are a lot of cool features built into it.
The program was announced through Bugcrowd. And we're already seeing a lot of people play around with it—at last count we were up to about 60 researchers.
Getting Technical: How Contrast’s Bug Bounty Works
The Contrast Security Bug Bounty program was designed for ease of use, low maintenance, and low cost. It is supported by a serverless application hosted on Amazon Web Services (AWS). Users start by visiting contrast.ninja. Returning users can simply sign in. New users are required to verify their Bugcrowd email through a process supported by AWS Cognito.
What we're doing here is fronting a website (contrast.ninja) with CloudFront, which authorizes using Cognito through AWS (you need an @bugcrowdninja email address). Once the user is authenticated, we then pass them forward to the contrast.ninja site.
Contrast TeamServer Bug Bounty registration
The user then hits launch.
Contrast Bug Bounty launch message
Contrast Bug Bounty email confirmation
We start some services on the back end in the ECS cluster. A containerized TeamServer environment is generated and fake data is added to it. It then gets served via email shortly thereafter. At that point, a researcher has their own personal instance of TeamServer to play around with.
Contrast Bug Bounty map
Researchers can stage attack attempts from any of the three user levels. For example, you can pretend to be a normal user and try to elevate your privileges. Or, you could try to fake data and do cross-site scripting (XSS) attacks. Alternatively, you could attempt injection attacks by modifying the actual website with code injections.
There are a lot of different avenues from which cyber criminals can attack an application. Since each researcher has their own personal user environment, you have the freedom to try whatever you can think up as an attack strategy. Each instance is a special, isolated copy of the Contrast TeamServer software existing within a safely containerized EC2 environment. Nothing you do will affect the production application.
If an attack successfully brings down the instance, the researcher can sign up for a new instance after 24 hours—or they can message us to have a new AWS token issued.
Contrast Bug Bounty instance deletion message
The 24-hour waiting period is related to some necessary time parameters on our end. Researchers can access the instance as long as they are active. However, inactivity for a 24-hour period results in the instance being shut down. Here, users get an email warning at the 23-hour mark; if they still fail to log in within the next hour, the instance is deleted. The 24-hour clock only starts once you go inactive. Researchers are welcome to sign up for a new instance post-deletion.
Reward and remediation chain
Researchers submit findings via tickets sent to Bugcrowd. Bugcrowd does some initial triage for us—a researcher will read through reported issues and determine if they are within our scope. Then, they attempt to exploit the respective issue in the same way the researcher did.
If Bugcrowd confirms the issue, they send it to me or one of the other researchers at Contrast Labs. At that point, we go ahead and triage it on our side and award points toward the researcher’s bounty reward. Then, we create a vulnerability management ticket. This is ultimately how a discovered bug gets fixed on our end.
Elevating the Broader Culture of Application Security
At Contrast, vulnerability disclosure isn’t just about improving our platform, but also about being part of a broader ecosystem for improving application security in general. Like CTF events, bug bounties are a tool that Contrast Labs security researchers use to extend our talent pool and expand our industry’s knowledge base. They also happen to be kind of fun—and they pay out better than CTFs.
On the upside, we recently increased our payouts on the Contrast Bug Bounty program, and over the next year, we’ll also be widening the program’s scope. This will give researchers a broader surface area to find vulnerabilities.
The bottom line is that application security can always be better. In fact, it must be. More than one-third (34%) of applications today have one or more serious vulnerabilities. It is our job to constantly evolve and try to stay ahead of the tools and tactics used by cyber criminals to exploit those vulnerabilities. The best way for security researchers to contribute to this ongoing process is to work together toward a common goal of eliminating all opportunities for security bypasses and software exploitation. And as a reminder, Contrast is always on the lookout to add talented researchers to this ongoing conversation.