singe/yellowUm wrapper binário simples para canarytokens de DNS.
_ _
_ _ ___| | | _____ __
| | | |/ _ \ | |/ _ \ \ /\ / /
| |_| | __/ | | (_) \ V V /
\__, |\___|_|_|\___/ \_/\_/
|___/
- Just add blue.
Modificações binárias simples que acionarão um canarytoken quando um binário for executado.
Ideal para armar armadilhas em sistemas de produção contra invasores.
Atualmente, existem quatro métodos:
Registre um canary token DNS próprio em canarytokens. Você pode ler mais sobre como eles funcionam em a documentação.
Ele parecerá algo assim: pz21qtyfsidipvrsuzs9n2udi.canarytokens.com
Coloque-o na variável de ambiente TOKEN com:
export TOKEN="c28y9l4dw0drj62un0cm4rwz6.canarytokens.com"
Os Dockerfiles contêm um token de exemplo funcional; você pode verificar o histórico de atividade dele aqui. Mas você realmente deveria usar o seu próprio.
Dockerfiles que implementam cada um desses métodos de compilação estão disponíveis.
Se você tiver um ambiente de build padrão adequado (ex.: build-essential em sistemas baseados em Debian ou build-base em sistemas baseados em Alpine), você pode compilar libyellow ou yellow de forma muito simples. ldsoyellow é mais complicado.
Você pode ver um exemplo simples de ponta a ponta de compilação e instalação do yellow nos Dockerfiles.
gcc -o yellow yellow.c canary32.c
Veja Dockerfile.yellow
Nenhuma compilação necessária.
Certifique-se de atualizar a lista de binários sobre os quais você quer alertar no array alert_list.
gcc -shared -fPIC libyellow.c canary32.c -o libyellow.so
Veja Dockerfile.libyellow ou Dockerfile.libyellow.debian para as versões Alpine e Debian.
Verifique o Dockerfile.ldsoyellow para um exemplo funcional. Você precisará das fontes do glibc (recomendo usar a versão oficial do pacote para ficar o mais próximo possível do linker real).
apt-get source libc6
Aplique o patch rtld.c.patch
cd /glibc-*
patch < rtld.c.patch
Configure o glibc com as verificações de sanidade desabilitadas e apontando para o libdir correto (assumindo um sistema de 64 bits)
mkdir glibcbuild && cd glibcbuild
/glibc-*/configure --disable-sanity-checks --libdir=$(dirname $(find / -name "libc.so.6"|grep 64))
Compile normalmente
make
Todas as variantes usam a variável de ambiente TOKEN para especificar a URL do canary token. O nome da variável de ambiente pode ser alterado, ou até mesmo embutido no código (hardcoded), se preferir. Novamente, existem Dockerfiles para cada uma delas.
O yellow tem a intenção de acionar em binários específicos que você renomeia e cria um alias para ele, de forma semelhante a como o busybox é usado. Você precisará renomear o binário para usar a extensão ".canary" e, em seguida, criar um symlink (ou cópia) do yellow com o nome do binário original. Por exemplo:
cp yellow /usr/bin
mv /usr/bin/id /usr/bin/id.canary
ln -s /usr/bin/yellow /usr/bin/id
Depois disso, qualquer execução de id acionará seu canary token.
Veja Dockerfile.yellow
O método de execução de processo sensível usa a mesma técnica acima, exceto que dispara com um script shell em vez de um binário, e vem com um instalador. Execute spe_install.sh passando seu token DNS e o nome do binário no qual você quer disparar. O binário não precisa existir.
Por exemplo:
./spe_install.sh "c28y9l4dw0drj62un0cm4rwz6.canarytokens.com" /bin/id
Isso criará um alerta sempre que id for executado.
Esta é uma cópia do método de token do Windows descrito aqui
O libyellow tem a intenção de disparar em qualquer binário usado em que tenha sido injetado via LD_PRELOAD, mas alertar apenas sobre os que você especificar no código. Isso pode ser feito por sessão, definindo a variável de ambiente LD_PRELOAD para apontar para ele, ou em todo o sistema, adicionando-o ao arquivo /etc/ld.so.preload. Esta última opção pode quebrar seu sistema se a biblioteca não estiver funcionando nele, então é recomendável testá-la usando LD_PRELOAD primeiro.
Lembre-se de colocar seu token na variável de ambiente TOKEN, conforme descrito em "Preparação" acima.
Exemplo com LD_PRELOAD:
cp libyellow.so /usr/lib/
export LD_PRELOAD=/usr/lib/libyellow.so
Em seguida, execute um binário alvo, verifique se ele se comporta como esperado e você receberá um alerta canary.
Quando estiver satisfeito de que tudo está funcionando, você pode adicioná-lo em todo o sistema com (isso não funcionará em sistemas baseados em musl, como Alpine, onde o método LD_PRELOAD é usado em vez disso):
cp libyellow.so /usr/lib
echo /usr/lib/libyellow.so >> /etc/ld.so.preload
Veja Dockerfile.libyellow ou Dockerfile.libyellow.debian para as versões Alpine e Debian.
O ldsoyellow tem a intenção de disparar em binários específicos em que o binário é modificado para usá-lo em vez do linker padrão. Você poderia substituir o linker padrão por ele para um efeito em todo o sistema, mas isso provavelmente geraria ruído demais.
O exemplo em Dockerfile.ldsoyellow inclui fazer isso para /bin/cat. Primeiro, o linker modificado é copiado ao lado do linker legítimo:
cp <arm'd linker> /lib64/ld-linux-x86-64.so.3
Em seguida, o binário é modificado para usá-lo em vez do legítimo:
sed -i "s/\/lib64\/ld-linux-x86-64.so.2/\/lib64\/ld-linux-x86-64.so.3/" /bin/cat
Veja Dockerfile.ldsoyellow.
Se você quisesse executar Docker em Docker, digamos, em um ambiente de build com controle limitado das diretivas de build, e ser alertado se alguém escapasse, você poderia fazer algo como o exemplo em Dockerfile.dind-rootless. Este exemplo usa yellow, mas poderia usar qualquer uma ou todas as outras variantes.
Ele cria armadilhas em binários no host que não deveriam ser acessíveis a partir de um contêiner.