singe/yellowUn simple envoltorio binario para canarytokens de DNS.
_ _
_ _ ___| | | _____ __
| | | |/ _ \ | |/ _ \ \ /\ / /
| |_| | __/ | | (_) \ V V /
\__, |\___|_|_|\___/ \_/\_/
|___/
- Just add blue.
Modificaciones binarias sencillas que activarán un canarytoken cuando se ejecute un binario.
Ideal para colocar trampas en sistemas de producción contra atacantes.
Actualmente hay cuatro métodos:
Registra tu propio token canario DNS en canarytokens. Puedes leer más sobre cómo funcionan en la documentación.
Se verá algo así: pz21qtyfsidipvrsuzs9n2udi.canarytokens.com
Ponlo en la variable de entorno TOKEN con:
export TOKEN="c28y9l4dw0drj62un0cm4rwz6.canarytokens.com"
Los Dockerfiles contienen un token de ejemplo que funciona; puedes consultar su historial de actividad aquí. Aunque realmente deberías usar el tuyo propio.
Hay Dockerfiles disponibles que implementan cada uno de estos métodos de compilación.
Si dispones de un entorno de compilación predeterminado adecuado (p. ej., build-essential en sistemas basados en Debian o build-base en sistemas basados en Alpine), puedes compilar libyellow o yellow de forma muy sencilla. ldsoyellow es más complejo.
Puedes ver un ejemplo sencillo de principio a fin de cómo compilar e instalar yellow en los Dockerfiles.
gcc -o yellow yellow.c canary32.c
Consulta Dockerfile.yellow
No requiere compilación.
Asegúrate de actualizar la lista de binarios sobre los que quieres alertar en el array alert_list.
gcc -shared -fPIC libyellow.c canary32.c -o libyellow.so
Consulta Dockerfile.libyellow o Dockerfile.libyellow.debian para las versiones Alpine y Debian.
Consulta Dockerfile.ldsoyellow para ver un ejemplo funcional. Necesitarás las fuentes de glibc (recomiendo usar la versión del paquete oficial para estar lo más cerca posible del enlazador real).
apt-get source libc6
Aplica el parche rtld.c.patch
cd /glibc-*
patch < rtld.c.patch
Configura glibc con las comprobaciones de sanidad deshabilitadas y apuntando al libdir correcto (asumiendo un sistema de 64 bits).
mkdir glibcbuild && cd glibcbuild
/glibc-*/configure --disable-sanity-checks --libdir=$(dirname $(find / -name "libc.so.6"|grep 64))
Compila con normalidad.
make
Todas las variantes usan la variable de entorno TOKEN para especificar la URL del token canario. El nombre de la variable de entorno se puede cambiar, o incluso fijarse directamente en el código si lo prefieres. De nuevo, existen Dockerfiles para cada una de ellas.
yellow está pensado para activarse con binarios específicos que renombras y conviertes en alias de yellow, de forma muy parecida a como se usa busybox. Tendrás que renombrar el binario para que use la extensión ".canary" y, a continuación, crear un enlace simbólico (o una copia) de yellow con el nombre del binario original. Por ejemplo:
cp yellow /usr/bin
mv /usr/bin/id /usr/bin/id.canary
ln -s /usr/bin/yellow /usr/bin/id
Después de esto, cualquier ejecución de id activará tu token canario.
Consulta Dockerfile.yellow
El método de ejecución de procesos sensibles usa la misma técnica que el anterior, salvo que se activa con un script de shell en lugar de un binario, y viene con un instalador. Ejecuta spe_install.sh pasándole tu token DNS y el nombre del binario sobre el que quieres activar la alerta. No es necesario que el binario exista.
Por ejemplo:
./spe_install.sh "c28y9l4dw0drj62un0cm4rwz6.canarytokens.com" /bin/id
Creará una alerta cada vez que se ejecute id.
Esto es una copia del método de token de Windows descrito aquí.
libyellow está pensado para activarse con cualquier binario en el que se haya inyectado mediante LD_PRELOAD, pero solo alertar sobre los que especifiques en el código. Esto puede hacerse por sesión configurando la variable de entorno LD_PRELOAD para que apunte a él, o en todo el sistema añadiéndolo al archivo /etc/ld.so.preload. Esta última opción puede romper tu sistema si la biblioteca no funciona en él, por lo que se recomienda probarla antes usando LD_PRELOAD.
Recuerda poner tu token en la variable de entorno TOKEN como se describe en "Trabajo previo" más arriba.
Ejemplo con LD_PRELOAD:
cp libyellow.so /usr/lib/
export LD_PRELOAD=/usr/lib/libyellow.so
Después ejecuta un binario objetivo, comprueba que se comporta como se espera y recibirás una alerta canary.
Una vez que estés conforme con que todo funciona, puedes añadirlo en todo el sistema con (esto no funcionará en sistemas basados en musl, como Alpine, donde se usa el método LD_PRELOAD en su lugar):
cp libyellow.so /usr/lib
echo /usr/lib/libyellow.so >> /etc/ld.so.preload
Consulta Dockerfile.libyellow o Dockerfile.libyellow.debian para las versiones Alpine y Debian.
ldsoyellow está pensado para activarse con binarios específicos cuando el binario se modifica para usarlo en lugar del enlazador predeterminado. Podrías reemplazar el enlazador predeterminado por él para conseguir un efecto en todo el sistema, pero probablemente sería demasiado ruidoso.
El ejemplo de Dockerfile.ldsoyellow incluye hacer esto para /bin/cat. Primero, el enlazador armado se copia junto al enlazador legítimo:
cp <arm'd linker> /lib64/ld-linux-x86-64.so.3
Luego, el binario se modifica para usarlo en lugar del legítimo:
sed -i "s/\/lib64\/ld-linux-x86-64.so.2/\/lib64\/ld-linux-x86-64.so.3/" /bin/cat
Consulta Dockerfile.ldsoyellow.
Si quisieras ejecutar Docker dentro de Docker, por ejemplo, en un entorno de compilación donde tuvieras un control limitado de las directivas de compilación, y recibir una alerta si alguien se escapara, podrías hacer algo como el ejemplo en Dockerfile.dind-rootless. Este ejemplo usa yellow, pero podría usar cualquiera de las otras variantes, o todas ellas.
Coloca trampas en los binarios del host que no deberían ser accesibles desde un contenedor.