SQL injection hacks are nothing new. In fact, with the ever growing boldness of bad actors and the proliferation of automated tools designed to ferret out components that lend themselves to this attack vector, there is no end in sight when it comes to compromising SQL. Given the powerful nature of the language, the potential for compromise is real and ugly.
Introducing CVE-2014-3483, a SQL injection attack on one of the most popular open source components
Name of the Vuln/Sonatype ID: CVE-2014-3483
Type of vulnerability: SQL Injection
Version(s) starting 4.0.0.beta1 and up to but excluding 4.0.7
Version(s) starting 4.1.0.beta1 and up to but excluding 4.1.3
Without sufficient escaping or sanitization of SQL statements, generated SQL query can cause inputs to be interpreted as SQL commands instead of ordinary user data by the processing engine. This can be used to alter query logic to bypass security checks, insert additional statements that compromise the back-end database, and in a worst case scenario, the execution of system commands.
The Attack Mechanics:
A lack of proper development hygiene is typically responsible for this particular attack - allowing the manipulation of less than well-written SQL code for nefarious purposes. Combine that with a software component that fails to properly construct all or part of a SQL command or incorrectly neutralizes (or fails to neutralize) specific elements that could modify that SQL command and the problem is compounded.
A Real-world example:
Let’s look at a real world example:
For those of you who prefer to read:
Let’s repeat the “Real World” here step-by-step, but a bit more simplified.
Vulnerable Code (left): values for the range field not being escaped properly. Fixed code (right) now escapes the 'range' field values prior to using them in SQL queries:
Vulnerable Code: values for the 'range' field not being escaped properly.
The best remediation path:
As discussed in the video, the most obvious way to prevent SQL injection attacks is to use proper development “hygiene” in addition to not blindly trusting code that looks syntactically correct.
In terms of CVE-2014-3483, it is recommended that you upgrade to non-vulnerable versions of the component versions 4.0.7 and 4.1.3 releases are available at the rubygems download locations.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2014-3483 within days of the discovery. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if you're using the vulnerable version of active record in a specific application, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out. For Ruby, include the vendor/cache folder after running "bundle package”.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.