Die Skripte in den Paketen rufen Seiten von Kommunalverwaltungsportalen der Londoner Bezirke Lambeth, Wandsworth und Southwark ab. Abgegriffen werden ausschließlich öffentlich einsehbare Inhalte wie Sitzungskalender, Tagesordnungen und Verweise auf Ausschüsse. Diese Daten werden anschließend als .gem-Archive wieder bei RubyGems veröffentlicht – über fest im Code hinterlegte API-Schlüssel.
Die technische Umsetzung variiert zwischen den Varianten. „In einigen Proben legt die Schadroutine unter /tmp eine temporäre RubyGems-Anmeldeumgebung an, überschreibt HOME, baut lokal ein Gem und schiebt es zu rubygems.org", heißt es im Blogbeitrag. Andere Varianten umgehen das Gem-Kommandozeilenwerkzeug vollständig und senden das Archiv direkt per POST an die RubyGems-Schnittstelle. Später lädt der Angreifer das Paket wieder herunter und entnimmt die Daten – ein Command-and-Control-Server ist dafür nicht nötig.
Mehrere Aspekte der Kampagne sind ungewöhnlich. Sie wurde zeitgleich mit einem offenbar koordinierten Spam-Veröffentlichungsangriff auf RubyGems beobachtet. Socket stellt keinen direkten Zusammenhang her, verweist aber auf ein ähnliches Missbrauchsmuster. Auffällig ist zudem, dass die Angreifer einen automatisierten Scraper mit Wurm-Potenzial geschaffen haben, ihn aber lediglich zum Sammeln öffentlicher Daten einsetzen, ohne die Pakete für klassische Köder zu nutzen.
Über das Motiv kann Socket nur spekulieren: „Es könnte sich um Registry-Spam handeln, um einen Machbarkeitsnachweis für einen Wurm, um einen automatisierten Scraper, der RubyGems als Speicherschicht zweckentfremdet, oder um einen gezielten Test von Registry-Missbrauch." Die Mechanik sei jedoch beabsichtigt: wiederholte Gem-Erzeugung, Versionssprünge, fest hinterlegte Zugangsdaten, direkte Veröffentlichungen und in den Archiven eingebettete Scraping-Daten.
Feross Aboukhadijeh, Gründer und CEO von Socket, nennt die Technik gegenüber Dark Reading raffiniert, die Ausführung jedoch „laut". Das deute eher auf Tests, Automatisierung oder Spam hin als auf eine ausgereifte Operation, die auf Tarnung achte. Möglicherweise sei es dem Akteur weniger ums Verborgenbleiben gegangen als darum, zu beweisen, dass RubyGems als Transportschicht taugt.
Obwohl keines der mehr als 155 betroffenen Pakete nennenswert heruntergeladen wurde, zeigt GemStuffer laut Socket einen neuartigen Missbrauch von Paketregistern als Dead Drop und ist ein Beleg dafür, dass solchen Registern nicht blind vertraut werden sollte. Organisationen, die Ruby-Pakete beziehen oder eine Betroffenheit vermuten, empfiehlt Socket, den Ordner /tmp auf möglicherweise betroffenen Maschinen zu prüfen, den Lieferweg zu ermitteln – da die Gems sich nicht selbst verbreiten – und in CI-Pipelines, die keine Gems veröffentlichen, ausgehende Gem-Uploads zu blockieren.
Das geschäftliche Risiko liege laut Aboukhadijeh weniger in den konkreten Schrott-Gems als in dem, was das Verhalten austeste. Sicherheitsteams konzentrierten sich oft auf die Frage, welche Pakete Entwickler installieren – doch auch die Veröffentlichungsaktivität verdiene Aufmerksamkeit. Verteidiger sollten wissen, welche Entwicklerrechner, CI-Jobs und Dienstkonten in öffentliche Register publizieren dürfen, und diese Abläufe so absichern, dass nur freigegebene Systeme freigegebene Pakete veröffentlichen.