00:00:08.530
Hi everybody, my name is Jason Meller. I'm the CEO and founder of Kolide, and this is Inoculating Rails Auth Against Bug Bounty Hunters, presented at RailsConf 2020.
00:00:15.519
So, a little bit about me before we get started. I guess the first half of my life, I was a bit of a script kiddie, breaking things here and there.
00:00:21.520
Then around 2010, I discovered Rails. As someone who started their career in cyber security, I found my passion was building web apps for people who wanted to fight the bad guys.
00:00:27.880
My career has been built on user experience coupled with cybersecurity, aiming to create effective tools for defenders who care about security issues.
00:00:39.070
As part of this journey, I founded a company called Kolide. Essentially, Kolide is a Rails app that focuses on security for devices. Rather than locking down devices, which we believe is a bad idea, especially for engineers who need full access, it identifies issues like security and policy violations and notifies users via Slack.
00:00:56.109
Instead of restricting firewall settings or device adjustments, we provide a helpful reminder when users are in violation of major events that could expose their companies to risk.
00:01:07.300
Examples include detecting unencrypted SSH keys that might provide access to production servers or identifying backups of production databases stored on hard drives.
00:01:12.670
We focus on less fear-based warnings and address real security issues rather than chasing after phantom threats posed by advanced threat actors.
00:01:18.729
Since Kolide is a Rails app, we faced numerous decisions regarding the security practices we wanted to implement, the first being user authentication.
00:01:26.799
Like most SaaS B2B applications, we needed a straightforward login system that allows users to log in with their username and password.
00:01:39.070
As with others, we were confronted with the build versus buy dilemma: should we implement a library like Devise or build our own solution from scratch? Typically, the advice is to focus on the core functionalities of your application rather than reinventing the wheel, especially when solutions have been refined by others.
00:01:51.010
However, for us, the calculus differed because we are a security company. It was crucial that we wholly owned and were responsible for the entire authentication flow.
00:02:05.700
This responsibility meant we had to ensure we could adapt our authentication processes as best practices evolved. If a newer, more secure method of authentication emerged, we wanted to be in position to understand and implement it.
00:02:16.490
The second and most important factor was understanding the needs of a B2B SaaS application. We knew we had to integrate all the bells and whistles typically expected: password-based authentication, SSO, and multi-factor authentication.
00:02:24.180
So, we aimed to build on a foundation that made sense while realizing that creating an effective authentication system would require significant effort.
00:02:35.970
We understood that authentication would occupy a majority – likely 60 to 70 percent – of the lines of code in our initial Ruby application.
00:02:46.950
It's crucial to get your authentication right; you cannot afford to treat it lightly, especially when working on a business application.
00:03:01.090
If you're questioning whether Devise still stands as a viable solution, I do believe it is a strong choice right now. With some enhancements around password complexity, which we will discuss later, it can serve you well.
00:03:12.299
This talk primarily revolves around bug bounty programs.
00:03:18.000
So, what exactly is a bug bounty program? To introduce this, let’s consider a scenario that these programs were designed to address.
00:03:29.870
Imagine a hacker who discovers a severe vulnerability in your application and is willing to disclose it, but only if compensated.
00:03:39.870
In the past, the typical response to hackers reaching out was, 'We don't negotiate with terrorists.' This defensive stance often leads to negative outcomes, as many companies react with anger and disdain when a hacker alerts them about vulnerabilities.
00:03:56.310
They might involve their lawyers for costly advice or issue scathing statements to the hacker that are ineffective and could even escalate the situation.
00:04:06.300
Worse, they might threaten the hacker, all while failing to recognize that this would only push the hacker toward publicly disclosing the vulnerability.
00:04:14.070
If you're unwilling to pay for vulnerability disclosures, you may find that hackers sell their findings to the highest bidder, sometimes leading to disastrous consequences for your user data and company reputation.
00:04:26.700
And if the hacker’s intentions are not criminal but rather show a responsibility to disclose vulnerabilities, they may choose to blog about their findings, including the entire exchange with the company.
00:04:36.810
In 99% of these scenarios, companies find themselves worse off, as their unwillingness to reward good actors can lead to reputational damage and a detrimental impact on their business.
00:04:48.390
Now let's consider the hacker’s perspective; what drives a hacker or a researcher to engage in responsible disclosure?
00:04:57.840
Many hackers enjoy breaking things and creatively circumventing security measures. However, in the past, it was challenging to operate within the law while doing so.
00:05:08.400
They often worried about potential legal repercussions for their actions, while also seeking fulfillment in their work.
00:05:18.350
Bug bounty programs present a legal and potentially profitable pathway for hackers to assist organizations in improving their security.
00:05:28.620
In return, organizations receive valuable insights at a fraction of the cost of traditional penetration testing.
00:05:37.240
If you decide to proceed with a bug bounty program, it’s essential to be aware of the potential pitfalls that may arise during its implementation.
00:05:48.520
One common mistake is adopting a defensive posture when researchers probe your application for vulnerabilities.
00:05:53.130
Researchers often generate noise in the form of exceptions, probing various endpoints. At this critical moment, you need to assess whether their actions affect user experience.
00:06:02.030
If you deem their probing to be harmless noise rather than a detriment, I encourage you to allow them to complete their job. The bug report they provide could reveal vulnerabilities you didn’t previously recognize.
00:06:10.550
Stopping their work prematurely negates much of the benefits your bug bounty program could provide.
00:06:18.170
Other common pitfalls involve trying to minimize rewards for valid reports or engaging in bad faith arguments about the bug's impact.
00:06:24.710
For instance, if researchers report a bug that has already been repeated in reports, it does not diminish its validity. You should incentivize continued efforts rather than undermining their contributions.
00:06:34.150
Another potential disaster is over-legislating your bug bounty program, placing too many constraints on scope, thus discouraging submissions.
00:06:44.210
A perfect example of this misstep occurred last summer with Valve’s bug bounty program, which gained significant media attention for all the wrong reasons.
00:06:50.850
Researchers reported several vulnerabilities pertaining to the Steam client, which were outside the established scope due to their requirement for file system access or physical device access.
00:07:09.300
Valve ultimately decided not to pay for these reports, resulting in the researcher disclosing the vulnerabilities publicly after being banned from the program.
00:07:18.440
This case reveals that overly strict scoping can cause companies to miss out on valuable security improvements while harming their reputation.
00:07:27.950
To avoid similar situations, apply a 'headline test' to each vulnerability report you receive.
00:07:35.600
Consider how you would feel if the report became a headline news story. If it makes you uncomfortable, you're wise to pay the hacker for their discovery.
00:07:46.220
In today’s world, many organizations have already established bug bounty programs. You may want to assess if yours can be improved.
00:07:53.500
Typically, hackers approach their job using an automated style, numerating as many organizations as possible to secure maximum financial gain.
00:08:02.640
Their process involves identifying low-hanging fruit with automated tools and then providing more in-depth services to those they find vulnerabilities with.
00:08:11.890
To do this, they must assess which vulnerabilities yield the best payout while requiring minimal effort to discover.
00:08:22.710
In the spectrum of vulnerabilities, they seek a balance between low payout, valid vulnerabilities and high payout vulnerabilities with potentially significant business impacts.
00:08:30.530
They likely focus their efforts on known OWASP top vulnerabilities, such as SQL injection, cross-site scripting, broken authentication, and session replay attacks.
00:08:41.570
Fortunately, Rails does a good job of mitigating many of these vulnerabilities at a basic level, but it’s essential that you ensure none of these issues are being inadvertently reintroduced into your application.
00:08:52.119
Hackers who target Rails applications may need to seek new methods of exploiting your application if they find those common vulnerabilities have already been patched.
00:09:03.250
As they look for ways to exploit Rails applications, they may employ chaining techniques, where they find lower payout vulnerabilities that can be combined with manual vulnerabilities to yield larger issues.
00:09:14.040
To illustrate, let me share a report we received early in Kolide’s life for an app that we no longer maintain.
00:09:23.110
This report documented five vulnerabilities that formed a vulnerability chain, which resulted in a payout of $1,350.
00:09:31.200
For us, as a fledgling startup, this was a significant expense, but the circumstances justified it. The first vulnerability was a cross-site scripting attack, which is inherently risky.
00:09:42.040
Following that, while we had a content security policy (CSP) to help with the attack mitigation, the attacker managed to bypass it.
00:09:50.610
They also exploited trivial cookies storing minimal data, such as email addresses for the 'Remember Me' feature.
00:09:59.570
Additionally, they discovered that they could enter any arbitrary value during the login process, as no validation checks restricted them from doing so.
00:10:09.690
Eventually, they able to perform an open redirect attack by chaining their findings, creating a scenario allowing them to redirect users to a spoofed page and capture their credentials.
00:10:18.550
Each individual vulnerability might have been worth $100 at most, but together, they became far more damaging.
00:10:26.850
This instance highlights the importance of preventing easy-to-exploit vulnerabilities, especially within the authentication space.
00:10:36.950
Overlooking minor vulnerabilities can lead to severe consequences, turning a small issue into one of significant liability.
00:10:47.540
Next, I want to share another real bug bounty report we received at Kolide, which only cost us $250, as it didn’t involve any chaining.
00:10:57.590
In this case, the basic premise was that the attacker already had access to a user's account.
00:11:10.069
The situation stemmed from the assumption that a valid session cookie was in use, even when an account password was changed.
00:11:19.000
Ultimately, the attacker could retain access indefinitely by repeatedly using this valid session, regardless of changes to the user's password.
00:11:25.360
How did this slip by, particularly in a well-constructed Rails app? The primary reason is that Rails’ session store employs cookies by default.
00:11:33.280
Since cookies are client-controlled, this makes server-initiated cookie revocation challenging.
00:11:40.870
Moreover, while Rails provides 'has_secure_password', it lacks the level of detail that libraries like Devise offer regarding password resets.
00:11:49.180
This situation exemplifies the risks associated with rolling your own authentication and the potential consequences.
00:11:56.859
To break down the vulnerability, we focus on the reported issues: lack of session revocation and inability to utilize it when necessary.
00:12:03.830
Additionally, there was a significant assumption about the attacker’s initial access to the user's account.
00:12:12.300
What allowed that access? Was it poor password quality, account enumeration, or the absence of multi-factor authentication measures?
00:12:17.860
Reflecting on that potential entry is crucial in order to bolster security against initial unauthorized access.
00:12:24.600
We need to assess password quality, updates and token challenges, and we must encompass a full security review based on these findings.
00:12:32.300
When it comes to password quality, consider implementing sophisticated complexity checks that go beyond old standards.
00:12:43.700
Throw out outdated practices like requiring passwords that are just a certain character length or contain specific symbols.
00:12:49.310
Instead, use tools that assess passwords against locale-specific dictionaries or databases of previously leaked password sets.
00:12:59.420
You should continually check passwords for users upon sign-in and account creation to prevent issues related to previously compromised passwords.
00:13:08.100
For example, the 'have I been pwned' service offers a gem that helps verify if a user’s password has leaked based on anonymized chunks without sexism.
00:13:16.140
By utilizing this, you can provide additional assurance to users in securing their accounts.
00:13:23.310
Now let's quickly address account enumeration. This is a critical consideration in your application's design.
00:13:31.300
By informing users whether their email exists in your system, you reveal potentially exploitable information.
00:13:39.710
Striking a solution that's not too revealing, but still adequately addresses user needs, is paramount to maintain security.
00:13:51.770
When it comes to multi-factor authentication, strong methods are critical. If you’re relying solely on passwords, you must complement them with robust multifactor techniques.
00:13:58.410
Outdated methods, like SMS-based multi-factor verification, have become less secure than alternatives such as time-based soft tokens.
00:14:06.090
Users should also be encouraged to use password managers, ensuring their keys are remembered and not stored insecurely.
00:14:14.150
There must be a clear policy in place to assist locked-out users whose means of access have been negated.
00:14:22.520
A well-thought-out multi-factor plan should outline necessary processes for these situations.
00:14:30.210
Additionally, we also face the threat of cross-site scripting (XSS). It's essential to have measures in place to prevent attackers from executing code in users' browsers.
00:14:38.890
Identifying unsafe usage of JavaScript, employing HTML escaping mechanisms, and implementing a robust content security policy (CSP) are essential steps.
00:14:46.860
Content Security Policy can serve as the last line of defense, working to define permissible sources for scripts, styles, and media.
00:14:54.230
However, be aware that ineffective CSP configurations can create exploitable vectors for hackers.
00:15:02.940
Finally, we must tackle the aftermath of vulnerabilities by utilizing audit logging. Detailed records allow users to understand actions taken by malicious actors.
00:15:15.650
Additionally, password re-prompting should be implemented for sensitive actions to ensure legitimate access.
00:15:24.370
This two-layer approach serves to limit damage if attackers gain access through session cookies.
00:15:34.280
Being deliberate in your strategy for verifying compromised accounts can significantly boost user security and improve their experience.
00:15:42.680
In closing, I have three key takeaways for you. First, carefully consider whether you're prepared to develop your own authentication system.
00:15:50.890
While it was an easy decision for us as a security company, your product type should guide this choice.
00:16:03.160
Second, if you don't have a bug bounty program, you should establish one, ensuring that your approach is well thought out and welcoming.
00:16:11.180
When you pay for bug reports, treat it as a valuable investment in your security.
00:16:18.880
Finally, inoculate your application from vulnerabilities by leveraging the techniques discussed today.
00:16:26.820
A robust resource to consider is the Rails security guide, which covers many of the topics discussed in this session.
00:16:34.650
Thank you for your time, and please feel free to reach out to me with any questions or comments.
