Security, Secrets and Shenanigans

Talks

Richard Schneeman

@schneems

#web-security

#security-vulnerability

#ruby-on-rails

#authentication

#environment-variables

#hacking

Security, Secrets and Shenanigans

by Richard Schneeman

In the video titled "Security, Secrets and Shenanigans," Richard Schneeman discusses the importance of web application security, focusing on common exploits and how developers can protect their code. The session aims to demystify security concepts and encourages developers to take responsibility for their code's security instead of relying solely on security researchers. Here's a breakdown of the key points discussed:

Introduction to Web Security: Richard opens by emphasizing that security risks often stem from developers' actions rather than the inherent flaws of the programming languages themselves.
Common Vulnerabilities: He explores a myriad of common security vulnerabilities, including:
- DDoS Attacks: Highlighting the challenges of keeping systems available amidst overwhelming traffic, Richard explains how malicious actors can exploit server vulnerabilities, particularly as user bases grow.
- Memory Exploits in Ruby: Discussion is made on symbols in Ruby and how improperly handled user input can deplete server memory, leading to outages.
- Parser Exploits: Richard illustrates XML parsing vulnerabilities with the "Billion Laughs" attack, stressing the importance of using robust parsers.
Authentication Security: Although briefly touched upon, authentication forms a core component of securing applications. Richard highlights the risks associated with YAML parsing and the need to avoid executing code during deserialization.
CSRF Risks: Addressing Cross-Site Request Forgery, Richard stresses the need for proper token configuration to prevent unauthorized access to forms.
Best Practices for Secret Management: He recommends that developers avoid hardcoding sensitive information in source control, employing environment variables instead to keep secrets safe. This also allows for dynamic configuration management without frequent redeployments.
Proactive Security Measures: Emphasizing proactive education, Richard encourages developers to stay informed about security vulnerabilities and participate in projects like Code Triage to help raise awareness and improve code security practices.

Conclusion: Richard urges developers to recognize that security is an ongoing process, highlighting that nothing is ever 100% secure. The key takeaways include using environment variables for secrets, adopting best practices to sanitize inputs, and continually educating oneself about security vulnerabilities to maintain robust applications. He closes his talk with an invitation for questions, fostering a collaborative approach to discussing security challenges in the developer community.

00:00:18.119 Hello everyone, my name is Richard Schneeman. On the internet, I go by @schneems. In the States, we have a hard time pronouncing that, so I like to say it’s like 'Schnauzer' or 'schnapps.' I was at the Munich Airport, and everybody, for some reason, thought I spoke German because my last name, 'Schneeman,' if you know any German, means 'snowman.' Yes, 'schnaman.' I absolutely love Ruby and am going to be marrying her on April 27th.

00:00:51.020 I have a dog named Hans Peter Von Wolf. His name is kind of long because he's a long dog. In fact, he’s the fifth, so we just call him Cinco. You might recognize me from such gems as 'Sexton.' If you don’t like running Rails routes in your project, you can use the Sexton Gem, and they will show up in your browser. This feature was also introduced in Rails 4, which is quite awesome! I'm really happy that that got picked up.

00:01:09.840 I’ve also written the 'Wicked' Gem, which is a way to generate step-by-step controller wizards. Most recently, I have a project called Code Triage, where you can get involved in open source projects. For instance, if you want to get more involved with Rails, you can sign up to triage Rails, and you will get a new open issue every single day. It’s a good way to learn more about the project and also to get involved—it’s pretty low impact.

00:01:47.700 I'm also an adjunct professor at the University of Texas. I did it mostly so I could actually say 'Good news, everyone!' They give you a card when you become a professor that allows you to do that. I have all my course materials online if you know anyone learning Rails. I’ve got about 40 hours of quizzes, lectures, and videos—all the videos are broken up into five-minute chunks and cover specific topics, so it’s not as intimidating as it sounds.

00:02:20.580 I work for Heroku, which is pretty awesome. However, it means I’m not allowed to wear this t-shirt that’s been circulating on the internet. I was at Australia RubyConf about eight days ago and then at Waza in San Francisco two days ago. Now I’m here. So, if I kind of spontaneously fall asleep in the middle of my talk, please don’t judge me. I’ve traveled a very long way.

00:02:54.840 I ask that you please close your laptops unless you’re triaging Rails issues. If that’s the case, you can definitely keep your laptops open. Okay, I have 27 minutes, and I want to talk to you about web security and what exactly it means to be secure. This is a hot button topic—recently, there have been many vulnerabilities.

00:03:14.040 I want to let you all know that I’m not a security researcher by any means, and I don’t think you have to be one either. We shouldn't just leave all of this to the security researchers with the mindset that it seems hard and that we don’t want to deal with it. This presentation will share knowledge to help you understand common security exploits and vulnerabilities while getting a better feel for what it means to write secure software.

00:03:58.739 Security bugs are essentially bugs that may not seem very significant. Some of the best-written software in the world is for the Space Program. For instance, according to something I found on Wikipedia, 42,000 lines of code across 11 different versions still had 17 errors. It’s impossible to write completely bug-free code; even something like 99.9999 percent uptime doesn’t mean bug-free.

00:04:10.319 By extension, if security bugs are just bugs in your software, it’s relatively safe to say that almost every device you own, your mobile phone, for example, has some sort of vulnerability. It’s just not necessarily publicly exploitable or commonly exploitable. Today, I want to talk about some common vulnerabilities, mitigation strategies, and ways we can improve our security processes.

00:04:41.520 Are you ready? Here we go! The first issue I want to discuss is availability, which often gets overlooked in the security space. Security isn’t just about keeping others out; sometimes it’s about ensuring that your system can stay up and remain available to your customers.

00:05:06.419 You might have heard of DDoS attacks, which stands for Distributed Denial of Service attacks. Imagine we have a server designed to handle a couple of connections globally. When numerous connections from around the world start hitting your server, it won't be able to cope, leading to unavailability. A part of this is what anonymous entities often do with their 'Low Orbit Ion Cannon'—a method of executing these attacks.

00:05:34.740 The most common way to avoid that attack is to block the IP addresses, but we can also increase the effectiveness of those attacks by sending malformed requests that our servers might choke on. These are important considerations, especially as your organization grows. If you have a couple of hundred or thousand users, you might not be a target. However, as you grow, people will attack you 'for the fun of it.'

00:06:01.100 Next, I want to touch on memory exploits. In Ruby, symbols are not fancy strings; they are actually optimized because symbols are never garbage collected in your program. If you take user input and call to_sym on it, you will create a symbol in memory that will never get garbage collected. If someone knows you’re doing this, they can exploit it by flooding your server with random junk, which can fill up your memory, ultimately bringing your server down.

00:06:44.400 Another issue is parser exploits. Has anyone heard of the 'Billion Laughs' exploit? This attack exploits XML by defining multiple XML entities that reference each previous one. Although it’s only a few kilobytes of code, when an XML parser tries to parse it, it expands those entities, taking up several gigabytes of RAM. If you send this numerous times, you can significantly disrupt a server, similar to a ZIP bomb for XML parsers.

00:07:29.100 Fortunately, most modern XML parsers are not as vulnerable to these kinds of attacks. It’s nice to know that they are generally mitigated, and it's another reason to rely on historically sturdy solutions, like using libxml2, rather than creating your own XML parser.

00:08:05.400 Now, let’s discuss authentication. I was looking through pictures and found one of armadillos—I wanted an excuse to show it to you. I can talk endlessly about authentication, but I need to condense my talk due to time constraints. Unfortunately, I won’t cover SQL injection attacks, but many users are familiar with YAML parsers and their exploits.

00:09:01.500 YAML stands for 'YAML Ain’t Markup Language.' It looks human-readable and writable, similar to hashes. We can serialize both basic and arbitrary objects with it. For instance, if we want to serialize a user within our YAML, whenever we load this, it can produce a Ruby object from the defined user class, sending attributes as keys and values.

00:09:37.200 While YAML is powerful, it can be insecure if we enable execution of code when instantiating an object. If we define a method that evaluates something during deserialization, it will execute arbitrary code, leading to significant security risks. This is particularly troubling if vulnerable classes are instantiated inappropriately.

00:10:47.160 A well-known vulnerability arose within the RubyGems. They directly loaded YAML, which posed security challenges, especially when combined with XML parsing features that allowed embedding YAML within XML. This vector made it so that vulnerable servers could get severely compromised by simply parsing malicious input. Therefore, if you haven’t updated your Rails, now’s the time. Ensure you’re using the latest versions available.

00:12:26.520 Recent events led to claims of Rails being insecure. While it may seem that programming languages like PHP or Java have their issues, it is more about how people utilize these languages rather than their intrinsic safety. In the coming year, there will be a renewed focus on ensuring safe practices concerning YAML usage, while also becoming aware that other serialization types like CSV or Marshalled objects can introduce their problems.

00:13:35.520 In general, always sanitize your user inputs. In this particular situation, the vulnerability was found before it even hit code lines relevant to Rails, which is somewhat out of individual programmers’ control. However, if you engaged actively in projects like Code Triage, you could help prevent issues from surfacing later on.

00:14:05.640 Just a note: never trust user inputs—or your dogs, for that matter! Mine once chewed through my driver's license, leaving it in no condition to use. Now, shifting gears to talk about something lighthearted—the ROBA, or 'Roomba Attack.' This happens when you have cords lying around, and your Roomba chomps through everything!

00:14:37.680 Despite the YAML vulnerabilities, one positive aspect emerged: responsible disclosure. Rails has a security report page that offers a detailed guide on reporting breaches. I suggest that organizations, especially those large enough, establish a security disclosure policy allowing individuals who find vulnerabilities to contact them before publicly disclosing on platforms like Hacker News.

00:15:58.360 I also highly recommend using off-site logging to keep track of activities, which won’t guarantee insight into whether you were exploited, but it can be beneficial. Services like Papertrail can help archive your logs, making it easier to search for suspicious behavior if a vulnerability is discovered.

00:17:01.560 Stay informed and subscribe to relevant security lists—this doesn’t have to be Rails-specific. If you manage your own VMs or VPS, ensure that you’re keeping up with operating system updates and patches, as outdated software can introduce as much risk as newly discovered vulnerabilities in your main application.

00:17:39.720 Now let's discuss secrets, particularly CSRF or Cross-Site Request Forgery. I created this slide prior to the YAML discussions. CSRF occurs when Rails verifies that a submitted form is from the same server, preventing unauthorized access from different sites. The key to your digital security in this process is properly configuring secure tokens.

00:18:10.620 Would you give keys to your car to your interns or apartment keys to contractors? If your secure keys reside within your source control, those credentials are at risk, especially if you add a collaborator or hire a contractor.

00:19:03.960 The best way to protect your code is to avoid storing secure keys within source control. Instead, consider using environment variables. For Rails, set that using environment variables by employing something like a .env file to define all your necessary values. You can utilize gems designed to manage these environment variables effectively, keeping sensitive information secure.

00:20:50.520 If you utilize Foreman or similar tools, they can automatically source that .env file, allowing Ruby to access the environment variables easily. But be cautious—if someone can read your environment variables, they can likely access your files too. Make sure you keep sensitive information confidential.

00:22:00.840 Overall, the challenge is determining the security of your application regarding secrets. This includes everything from database credentials to API keys and other sensitive data. Reflect on whether you could safely make your repository public without risking your customers' data.

00:23:45.200 Using environment variables allows you to change configurations on-the-fly, meaning you won’t have to re-deploy code as frequently. This leads to better management of your secrets without hardcoding them in your repository. Furthermore, one request I would make for Rails is to enable rotatable keys for security. Currently, you can only have one token at a time.

00:25:05.640 In summary, nothing is ever 100% secure. Always educate yourself about prevalent security vulnerabilities. Actively seeking input from coworkers and professional communities will help raise awareness. With regards to secrets, please avoid storing them in git. Use environment variables when possible.

00:26:30.400 So, to finish up, the title of my talk is 'Security, Secrets, and Shenanigans.' I also want to encourage you all: vote for Ruby Hero! It doesn’t have to be Terence Lee, but instead, ask yourself not what Bundler can do for you, but what you can do for your Bundler maintainer.

00:27:48.500 I have a few more minutes before I wrap this up. Does anyone have questions?

00:31:16.740 Yes, please feel free to ask your questions—no question is too small. Just as you would want to explore any security issues in your setups, it’s good practice to discuss them in our community. Today, we’ll have another panel about security after lunch to further explore these topics.

wroc_love.rb 2013