_ _
_ _ ___| | | _____ __
| | | |/ _ \ | |/ _ \ \ /\ / /
| |_| | __/ | | (_) \ V V /
\__, |\___|_|_|\___/ \_/\_/
|___/
- Just add blue.
バイナリを実行した際に canarytoken をトリガーする、シンプルなバイナリ改変です。
攻撃者に対する本番システムのブービートラップ化に最適です。
現在、4つの方法があります：
独自の DNS canary token を canarytokens で登録してください。それらの仕組みについては ドキュメント で詳しく読めます。
次のような形式になります: pz21qtyfsidipvrsuzs9n2udi.canarytokens.com
それを環境変数 TOKEN に設定します:
export TOKEN="c28y9l4dw0drj62un0cm4rwz6.canarytokens.com"
Dockerfile には動作するサンプルトークンが含まれています。そのアクティビティ履歴は こちら で確認できます。ただし、実際には独自のトークンを使うべきです。
これらの各ビルド方法を実装した Dockerfile が用意されています。
適切なデフォルトのビルド環境（例: Debian 系システムの build-essential や Alpine 系システムの build-base）があれば、libyellow または yellow を非常に簡単にコンパイルできます。ldsoyellow はもう少し複雑です。
Dockerfile 群に、yellow のビルドとインストールの単純なエンドツーエンドの例があります。
gcc -o yellow yellow.c canary32.c
Dockerfile.yellow を参照してください。
ビルドは不要です。
アラート対象にしたいバイナリのリストを、alert_list 配列で必ず更新してください。
gcc -shared -fPIC libyellow.c canary32.c -o libyellow.so
Alpine 版と Debian 版については、Dockerfile.libyellow または Dockerfile.libyellow.debian を参照してください。
動作例については Dockerfile.ldsoyellow を確認してください。glibc のソースが必要です（実際のリンカにできる限り近づけるため、公式パッケージ版を使うことをお勧めします）。
apt-get source libc6
パッチ rtld.c.patch を適用します。
cd /glibc-*
patch < rtld.c.patch
サニティチェックを無効にし、正しい libdir を指すように glibc を構成します（64ビットシステムを想定）。
mkdir glibcbuild && cd glibcbuild
/glibc-*/configure --disable-sanity-checks --libdir=$(dirname $(find / -name "libc.so.6"|grep 64))
通常どおりビルドします。
make
すべてのバリアントは、canary token の URL を指定するために TOKEN 環境変数を使用します。環境変数名は変更できますし、必要であればハードコードすることもできます。繰り返しますが、それぞれに対応する Dockerfile があります。
yellow は、busybox と同じように、リネームして yellow へのエイリアスとして使う特定のバイナリに対してトリガーすることを意図しています。バイナリを ".canary" 拡張子を使うようにリネームし、元のバイナリ名で yellow へのシンボリックリンク（またはコピー）を作成する必要があります。例：
cp yellow /usr/bin
mv /usr/bin/id /usr/bin/id.canary
ln -s /usr/bin/yellow /usr/bin/id
この後、id を実行すると canary token がトリガーされます。
Dockerfile.yellow を参照してください。
sensitive process execution（機密プロセス実行）方式は上記と同じ手法を使いますが、バイナリではなくシェルスクリプトでトリガーし、インストーラが付属しています。DNS トークンと、トリガーしたいバイナリの名前を渡して spe_install.sh を実行してください。そのバイナリが存在している必要はありません。
例:
./spe_install.sh "c28y9l4dw0drj62un0cm4rwz6.canarytokens.com" /bin/id
これにより、id が実行されるたびにアラートが作成されます。
これは ここ で説明されている Windows トークン方式のコピーです。
libyellow は、LD_PRELOAD 経由で注入された状態で使用される任意のバイナリに対してトリガーすることを意図していますが、アラートを出すのはコード内で指定したものだけです。これは、LD_PRELOAD 環境変数をそれに向けて設定することでセッション単位で行うこともできますし、/etc/ld.so.preload ファイルに追加することでシステム全体で行うこともできます。後者は、ライブラリがそのシステムで動作していない場合にシステムを壊す可能性があるため、最初に LD_PRELOAD を使ってテストすることをお勧めします。
上記の「事前準備」で説明したとおり、TOKEN 環境変数にトークンを設定することを忘れないでください。
LD_PRELOAD の例:
cp libyellow.so /usr/lib/
export LD_PRELOAD=/usr/lib/libyellow.so
その後、対象のバイナリを実行し、期待どおりに動作することを確認すると、canary アラートが届きます。
すべてが動作していることを確認できたら、次の方法でシステム全体に追加できます（これは Alpine のような musl ベースのシステムでは機能しません。そのようなシステムでは代わりに LD_PRELOAD 方式を使用してください）：
cp libyellow.so /usr/lib
echo /usr/lib/libyellow.so >> /etc/ld.so.preload
Alpine 版と Debian 版については、Dockerfile.libyellow または Dockerfile.libyellow.debian を参照してください。
ldsoyellow は、デフォルトのリンカの代わりにそれを使うように変更された特定のバイナリに対してトリガーすることを意図しています。システム全体に影響を与えるためにデフォルトのリンカをこれに置き換えることもできますが、おそらくノイズが多すぎるでしょう。
Dockerfile.ldsoyellow の例では、/bin/cat に対してこれを行っています。まず、トリガーを仕込んだリンカを正規のリンカの隣にコピーします：
cp <arm'd linker> /lib64/ld-linux-x86-64.so.3
次に、バイナリが正規のリンカの代わりにそれを使用するよう変更されます：
sed -i "s/\/lib64\/ld-linux-x86-64.so.2/\/lib64\/ld-linux-x86-64.so.3/" /bin/cat
Dockerfile.ldsoyellow を参照してください。
たとえば、ビルドディレクティブをあまり制御できないビルド環境で Docker in Docker を実行し、誰かがコンテナから脱出した場合にアラートを受け取りたい場合、Dockerfile.dind-rootless の例のようなことができます。この例は yellow を使用していますが、他のバリアントのいずれかまたはすべてを使用することもできます。
コンテナからアクセスできるべきではないホスト上のバイナリにブービートラップを仕掛けます。