Ruby On Rails - man in the middle attack when a gem uses in its Gemfile HTTP source?

user_6060322 0
Viewed 119

I'm running a security scanner against an app I'm developing and it's rising red alert, maximum security thread for the gem rotr which uses in its Gemfile source with HTTP protocol revealing a possibility for man in the middle attack that potentially can allow an attacker to inject any code into an application

The link to Gemfile in question - https://github.com/mdp/rotp/blob/master/Gemfile

It states:

source 'http://rubygems.org'

Is it real issue if this gem listed as a dependency and in my Gemfile I'm using:

source 'https://rubygems.org'

I tried to find out how exactly it's working but wasn't able to.

I.e. which way bundler is working:

  1. It pulls all gems I specify from https://rubygems.org, then it pull all dependencies separately for each gem, from the source specified in each Gemfile (for each gem) and in case of ropt gem it pulls from http://rubygems.org (NOT https) - thus opening theoretical possibility for man in the middle attack while installing ropt gem

  2. Bundler pulls all gem from the source specified in MY Gemfile (https://rubygems.org) so even if a Gem specifies http://rubygems.org (NOT https) - it'll be pulled through the secure protocol from the location I specify so there is no theoretical possibility for man in the middle attack

gemfile bundler ruby-on-rails ruby
1 Answers

In your example, the gem would be loaded via HTTPS, because the Gemfile of a dependency will not be loaded at all. From dependencies, only the gemspec file is evaluated by Bundler. The gem's Gemfile is only used during the development of that gem. Interesting read in this context: How bundler priorities sources.

The following for the interested reader why it is important to use HTTPS when downloading gems:

When you load a gem from a non-HTTPS source and there is a man-in-the-middle attacker then this attacker would be able to send you back anything instead of the gem you requested.

Of course, there are man ifs and whens. But let's imagine you are going to download a gem on a non-secure communication channel like pure HTTP. And let's imagine there is a man-in-the-middle attacker that is able to sniff your traffic. This might be possible when using the same WiFi in a café or hotel, or when there are different customers on virtual servers in a data center or they have physical access to your landline.

Because they can read your unencrypted request for a gem then know what gems you are using. Now imagine that they do not just sniff your traffic but instead manipulate the response from the servers to you too. When you, for example, request a new version of a popular gem to handle user authentication and authorization or payments they could send you back their version instead of the original version.

And their version could include some minor changes like:

  • when loaded the gem could upload your Gemfile to the attacker which would give the attacker a great overview of your application.
  • when loaded the gem could take all ENV variables and/or Rails.credentials and upload them to a server that is controlled by the attacker. This would certainly git the attacker all your application's passwords.
  • because it changed the original gem dealing with user credentials the malicious gem would be able to track users or your admin credentials when they log in or update their credentials. Given that many users use the same email/password combination everywhere this would be a nightmare.
  • if the gem can read ENV variables or Rails.credentials then that means that it could change them too. For example, to connect to another payment provider would mean your customer's payment would be redirected into a different account.
  • And on top of that, the malicious gem could also replace itself with the original gem once it was loaded into memory. What would make it difficult to figure out that your server was attacked.

tl;dr When an attacker is able to do a man-in-the-middle attack then they can send you malicious versions of a gem. These malicious gems could do almost everything with your application you can imagine. Sure, attacks like this are not simple, but they are not super-hard neither.

The rule of thumb is: Always use HTTPS whenever possible (not just for downloading gem but for all network traffic).

user_24833130
Related