Updates in dependencies
It’s October, and you know what that means, SECURITY AWARENESS MONTH! This year for security awareness month I’ll be writing some blog posts about security concerns. Some of these things won’t be new to everyone but they’ll be great general reminders of things happening around us in cyber security.
Today we’re talking about updates in dependencies. Still lingering in everyone’s mind is the recent hack at Equifax. While the amount of data leaked here wasn’t the most impressive by a long shot the sensitivity of this data makes it quite possibly the single worst data compromise in history. The most sensitive information used to identify people was compromised and leaked. Pieces of information that simply cannot be changed like Birthday, SSN and much much more.
So What happened?
Equifax’s core website was built, like so many other sites are, on a framework. Frameworks are incredibly powerful and useful they mean taht the time it takes to write web applications is minimised greatly because much of the common core has been created for you. But it doesn’t stop there, the work on the framework has only just begun once it is released. As more and more applications are built on the framework new features are added and bugs are fixed. Often times it becomes all too easy to ignore these updates. We think we don’t need the new features. We didn’t have them when we built our application and our application may not even have a need for the new features now so we ignore them. Bug fixes are applied to things but we think that because those bugs aren’t affecting us in a manor that we can see or that our users report then the bug doesn’t apply to us. In some cases those might be valid assessments, however not all bugs affect the proper use of an application, and will therefore NEVER be identified by a user.
CVE (Common Vulnerabilities and Exposures)
One of the single largest benefits of a framework is often overlooked and undervalued. The fact that frameworks are widely used also means they are much more widely tested from a security standpoint. Security researchers will run extensive tests against a wide array of tests from XSS to SQLI, privilege escalation, RCE, CSRF and more. What’s more is these tests are done using many different fuzzing techniques by many different researchers. Due to the nature of fuzzing you could fuzz a library for days and find nothing and someone else could fuzz the same library with the same tools for an hour and find huge flaws. These flaws when discovered by a white hat will be reported responsibly to the vendor to allow security fixes to be applied before the details are revealed publicly. Once revealed however these CVEs become part of tools available to every White Hat, Grey Hat, Black Hat and SKID on the internet.
Does this really affect us?
YES! This affects pretty much EVERYONE. In today’s modern applications it is almost impossible to not use a framework or a library from someone else. The minute you are using someone else’s code, you are opening yourself up to future CVEs in that code affecting you, your application and your company.
What can we do?
The only thing you can do is update early and update often. This means we should be rolling out gem updates do our testing environments much more regularly than we do. Especially core framework components. These components are trusted with the most sensitive parts of an application, authentication & authorisation, session management, database connections, query sanitation and much more. The servers that run our rails application have some of the most critical information and configuration details on them. Details that could allow an attacker unfettered access to our databases, S3 buckets and all the PII that we store on users.
Another thing you can do is use open-source dependency CVE tools. Here is a great article detailing 13 tools for checking the security risk of open-source dependencies. These tools should have you covered regardless of the language or framework you’re working with.