singe/yellowUn simple wrapper binaire pour les canarytokens DNS.
_ _
_ _ ___| | | _____ __
| | | |/ _ \ | |/ _ \ \ /\ / /
| |_| | __/ | | (_) \ V V /
\__, |\___|_|_|\___/ \_/\_/
|___/
- Just add blue.
Modifications binaires simples qui déclencheront un canarytoken lorsqu'un binaire est exécuté.
Idéal pour piéger des systèmes de production contre les attaquants.
Il existe actuellement quatre méthodes :
Enregistrez votre propre canary token DNS sur canarytokens. Vous pouvez en savoir plus sur leur fonctionnement dans la documentation.
Cela ressemblera à ceci : pz21qtyfsidipvrsuzs9n2udi.canarytokens.com
Placez-le dans la variable d'environnement TOKEN avec :
export TOKEN="c28y9l4dw0drj62un0cm4rwz6.canarytokens.com"
Les Dockerfiles contiennent un exemple de jeton fonctionnel ; vous pouvez consulter son historique d'activité ici. Vous devriez vraiment utiliser le vôtre cependant.
Des Dockerfiles implémentant chacune de ces méthodes de compilation sont disponibles.
Si vous disposez d'un environnement de compilation par défaut approprié (par exemple build-essential sur les systèmes basés sur Debian ou build-base sur les systèmes basés sur Alpine), vous pouvez compiler libyellow ou yellow très simplement. ldsoyellow est plus complexe.
Vous pouvez voir un exemple simple de bout en bout de compilation et d'installation de yellow dans les Dockerfiles.
gcc -o yellow yellow.c canary32.c
Voir Dockerfile.yellow
Aucune compilation requise.
Assurez-vous de mettre à jour la liste des binaires pour lesquels vous souhaitez être alerté dans le tableau alert_list.
gcc -shared -fPIC libyellow.c canary32.c -o libyellow.so
Voir Dockerfile.libyellow ou Dockerfile.libyellow.debian pour les versions Alpine et Debian.
Consultez le Dockerfile.ldsoyellow pour un exemple fonctionnel. Vous aurez besoin des sources glibc (je recommande d'utiliser la version officielle du paquet pour être aussi proche que possible du vrai linker).
apt-get source libc6
Appliquez le correctif rtld.c.patch
cd /glibc-*
patch < rtld.c.patch
Configurez glibc avec les vérifications de cohérence désactivées et en pointant vers le bon libdir (en supposant un système 64 bits)
mkdir glibcbuild && cd glibcbuild
/glibc-*/configure --disable-sanity-checks --libdir=$(dirname $(find / -name "libc.so.6"|grep 64))
Compilez normalement
make
Toutes les variantes utilisent la variable d'environnement TOKEN pour spécifier l'URL du canary token. Le nom de la variable d'environnement peut être modifié, voire codé en dur si vous préférez. Encore une fois, des Dockerfiles existent pour chacune de ces méthodes.
yellow est conçu pour se déclencher sur des binaires spécifiques que vous renommez et vers lesquels vous créez un alias, un peu comme busybox. Vous devrez renommer le binaire pour utiliser l'extension ".canary", puis créer un lien symbolique (ou une copie) de yellow sous le nom du binaire d'origine. Par exemple :
cp yellow /usr/bin
mv /usr/bin/id /usr/bin/id.canary
ln -s /usr/bin/yellow /usr/bin/id
Après cela, toute exécution de id déclenchera votre canary token.
Voir Dockerfile.yellow
La méthode d'exécution de processus sensibles utilise la même technique que ci-dessus, sauf qu'elle se déclenche avec un script shell plutôt qu'avec un binaire, et est fournie avec un installateur. Exécutez spe_install.sh en lui passant votre token DNS et le nom du binaire sur lequel vous voulez déclencher. Le binaire n'a pas besoin d'exister.
Par exemple :
./spe_install.sh "c28y9l4dw0drj62un0cm4rwz6.canarytokens.com" /bin/id
Créera une alerte à chaque fois que id sera exécuté.
Ceci est une copie de la méthode du jeton Windows décrite ici
libyellow est conçu pour se déclencher sur tout binaire utilisé lorsqu'il a été injecté via LD_PRELOAD, mais n'alerte que sur ceux que vous spécifiez dans le code. Cela peut être fait par session en définissant la variable d'environnement LD_PRELOAD pour y pointer, ou à l'échelle du système en l'ajoutant dans le fichier /etc/ld.so.preload. Cette dernière option peut casser votre système si la bibliothèque ne fonctionne pas dessus, il est donc recommandé de la tester d'abord avec LD_PRELOAD.
N'oubliez pas de mettre votre jeton dans la variable d'environnement TOKEN comme décrit dans « Pré-requis » ci-dessus.
Exemple LD_PRELOAD :
cp libyellow.so /usr/lib/
export LD_PRELOAD=/usr/lib/libyellow.so
Exécutez ensuite un binaire cible, vérifiez qu'il se comporte comme prévu, et vous recevez une alerte canary.
Une fois que vous êtes satisfait que tout fonctionne, vous pouvez l'ajouter à l'échelle du système avec (cela ne fonctionnera pas sur les systèmes basés sur musl comme Alpine, où la méthode LD_PRELOAD est utilisée à la place) :
cp libyellow.so /usr/lib
echo /usr/lib/libyellow.so >> /etc/ld.so.preload
Voir Dockerfile.libyellow ou Dockerfile.libyellow.debian pour les versions Alpine et Debian.
ldsoyellow est conçu pour se déclencher sur des binaires spécifiques où le binaire est modifié pour l'utiliser à la place du linker par défaut. Vous pourriez remplacer le linker par défaut par celui-ci pour un effet à l'échelle du système, mais cela serait probablement trop bruyant.
L'exemple Dockerfile.ldsoyellow inclut cette opération pour /bin/cat. D'abord, le linker modifié est copié à côté du linker légitime :
cp <arm'd linker> /lib64/ld-linux-x86-64.so.3
Ensuite, le binaire est modifié pour l'utiliser à la place du linker légitime :
sed -i "s/\/lib64\/ld-linux-x86-64.so.2/\/lib64\/ld-linux-x86-64.so.3/" /bin/cat
Voir Dockerfile.ldsoyellow.
Si vous vouliez exécuter Docker in Docker pour, disons, un environnement de compilation où vous avez un contrôle limité des directives de compilation, et être alerté si quelqu'un s'en échappait, vous pourriez faire quelque chose comme l'exemple dans Dockerfile.dind-rootless. Cet exemple utilise yellow mais pourrait utiliser n'importe laquelle ou toutes les autres variantes.
Il piège des binaires sur l'hôte qui ne devraient pas être accessibles depuis un conteneur.