_ _               
 _   _  ___| | | _____      __
| | | |/ _ \ | |/ _ \ \ /\ / /
| |_| |  __/ | | (_) \ V  V / 
 \__, |\___|_|_|\___/ \_/\_/  
 |___/               
 - Just add blue.

yellow - basta aggiungere blu

Semplici modifiche binarie che attiveranno un canarytoken quando un binario viene eseguito.

Ideale per disseminare trappole nei sistemi di produzione contro gli attaccanti.

Attualmente ci sono quattro metodi:

• yellow è un approccio mirato con un binario che attiva il token e poi esegue il binario reale basandosi su un'estensione di file a tua scelta.
• spe è una variazione di quanto sopra usando un approccio simile al token “Sensitive Process Execution” recentemente aggiunto da Thinkst per Windows.
• libyellow è una notifica tra sistemi e attiverà in modo trasparente un canarytoken per qualsiasi nome di binario tu specifichi quando viene iniettato tramite LD_PRELOAD
• ldsoyellow è un linker glibc pienamente funzionante (ld.so) che attiva un canarytoken per qualsiasi binario che lo utilizza

Preparazione

Registra un DNS canary token tuo personale su canarytokens. Puoi leggere di più su come funzionano nella documentazione.

Sarà qualcosa del genere: pz21qtyfsidipvrsuzs9n2udi.canarytokens.com

Inseriscilo nella variabile d'ambiente TOKEN con: export TOKEN="c28y9l4dw0drj62un0cm4rwz6.canarytokens.com"

I Dockerfile contengono un token di esempio funzionante; puoi controllare la sua cronologia delle attività qui. Dovresti comunque usare il tuo.

Compilazione

Sono disponibili Dockerfile che implementano ciascuno di questi metodi di build.

Se hai un ambiente di build predefinito adatto (ad es. build-essential su sistemi basati su Debian o build-base su sistemi basati su Alpine), puoi compilare libyellow o yellow molto semplicemente. ldsoyellow è più complesso.

Puoi vedere un semplice esempio end-to-end di build e installazione di yellow nei Dockerfile.

yellow

gcc -o yellow yellow.c canary32.c

Vedi Dockerfile.yellow

spe

Nessuna compilazione richiesta.

libyellow

Assicurati di aggiornare l'elenco dei binari su cui vuoi ricevere avvisi nell'array alert_list.

gcc -shared -fPIC libyellow.c canary32.c -o libyellow.so

Vedi Dockerfile.libyellow o Dockerfile.libyellow.debian per le versioni Alpine e Debian.

ldsoyellow

Controlla il Dockerfile.ldsoyellow per un esempio funzionante. Ti serviranno i sorgenti glibc (consiglio di usare la versione ufficiale del pacchetto per essere il più vicino possibile al linker reale).

apt-get source libc6

Applica la patch rtld.c.patch

cd /glibc-* patch < rtld.c.patch

Configura glibc con i sanity check disabilitati e puntando alla libdir giusta (supponendo un sistema a 64 bit)

mkdir glibcbuild && cd glibcbuild /glibc-*/configure --disable-sanity-checks --libdir=$(dirname $(find / -name "libc.so.6"|grep 64))

Compila normalmente

make

Installazione

Tutte le varianti usano la variabile d'ambiente TOKEN per specificare l'URL del canary token. Il nome della variabile d'ambiente può essere cambiato, o addirittura hardcodato se preferisci. Anche in questo caso, esistono Dockerfile per ciascuno di questi metodi.

yellow

yellow è pensato per attivarsi su binari specifici che rinomini e a cui crei un alias, un po' come viene usato busybox. Dovrai rinominare il binario usando l'estensione ".canary", quindi creare un symlink (o una copia) di yellow con il nome del binario originale. Per esempio:

cp yellow /usr/bin
mv /usr/bin/id /usr/bin/id.canary
ln -s /usr/bin/yellow /usr/bin/id

Dopo questo, qualsiasi esecuzione di id attiverà il tuo canary token.

Vedi Dockerfile.yellow

spe

Il metodo sensitive process execution usa la stessa tecnica di cui sopra, tranne per il fatto che si attiva con uno script shell piuttosto che con un binario, ed è dotato di un installer. Esegui spe_install.sh passandogli il tuo DNS token e il nome del binario su cui vuoi attivare l'avviso. Il binario non deve necessariamente esistere.

Per esempio: ./spe_install.sh "c28y9l4dw0drj62un0cm4rwz6.canarytokens.com" /bin/id

Creerà un avviso ogni volta che id viene eseguito.

Questa è una copia del metodo token per Windows descritto qui

libyellow

libyellow è pensato per attivarsi su qualsiasi binario usato quando è stato iniettato tramite LD_PRELOAD, ma per avvisare solo su quelli specificati nel codice. Questo può essere fatto per sessione impostando la variabile d'ambiente LD_PRELOAD in modo che punti ad esso, oppure a livello di sistema aggiungendolo al file /etc/ld.so.preload. Quest'ultima opzione può rompere il sistema se la libreria non funziona correttamente, quindi è consigliato testarla prima usando LD_PRELOAD.

Ricorda di inserire il tuo token nella variabile d'ambiente TOKEN come descritto nella sezione "Preparazione" qui sopra.

Esempio di LD_PRELOAD:

cp libyellow.so /usr/lib/
export LD_PRELOAD=/usr/lib/libyellow.so

Quindi esegui un binario di destinazione, verifica che si comporti come previsto e riceverai un avviso canary.

Quando sei soddisfatto che tutto funzioni, puoi aggiungerlo a livello di sistema con (questo non funzionerà su sistemi basati su musl come Alpine, dove si usa invece il metodo LD_PRELOAD):

cp libyellow.so /usr/lib
echo /usr/lib/libyellow.so >> /etc/ld.so.preload

Vedi Dockerfile.libyellow o Dockerfile.libyellow.debian per le versioni Alpine e Debian.

ldsoyellow

ldsoyellow è pensato per attivarsi su binari specifici in cui il binario viene modificato per usarlo al posto del linker predefinito. Potresti sostituire il linker predefinito con esso per un effetto a livello di sistema, ma probabilmente sarebbe troppo rumoroso.

L'esempio Dockerfile.ldsoyellow include questa operazione per /bin/cat. Prima il linker armato viene copiato accanto al linker legittimo:

cp <arm'd linker> /lib64/ld-linux-x86-64.so.3

Poi il binario viene modificato per usarlo al posto di quello legittimo:

sed -i "s/\/lib64\/ld-linux-x86-64.so.2/\/lib64\/ld-linux-x86-64.so.3/" /bin/cat

Vedi Dockerfile.ldsoyellow.

Esempio Docker in Docker

Se volessi eseguire Docker in Docker per, ad esempio, un ambiente di build in cui hai un controllo limitato delle direttive di build, ed essere avvisato se qualcuno riuscisse a evadere, potresti fare qualcosa di simile all'esempio in Dockerfile.dind-rootless. Questo esempio usa yellow ma potrebbe usare una qualsiasi o tutte le altre varianti.

Mette trappole nei binari dell'host che non dovrebbero essere accessibili da un container.