サイバーセキュリティ演習のための攻撃シナリオ策定と環境構築【日本総研インターン】
12月7日から12月18日まで,株式会社日本総合研究所で行われたインターンに参加させて頂きました.
やったこと
日本総研のセキュリティ統括部というところに配属されて,「サイバーセキュリティ演習のための攻撃シナリオの策定と環境構築」というテーマに取り組みました.
SMBCグループのような金融機関は特にサイバー攻撃の対象になりやすく,そのため普段からセキュリティ演習が行われています.しかし,環境がWindows中心や有名な脆弱性をつくものが多く,多少偏りがあると言えます.そこで私はLinuxの知識が必要となるような演習で,さらにこれから確実に必要となってくるコンテナセキュリティを絡めたものを作成することにしました.
基本的には,まず攻撃手法の選定を行い,それを基にシナリオの策定と環境の構築を行いました.
攻撃シナリオと演習環境
簡易的ではありますが,下図のような環境を想定しました.
攻撃者は機密情報コンテナにアクセスすることを最終目的とします.
以下が策定した攻撃シナリオです.
PC1ユーザを攻撃者が用意したWebサイトに誘導し,リバースシェルを開かせるマルウェアをダウンロードさせ,実行させる.
PC1を踏み台にし,内部LANからしかアクセスできないSambaコンテナにアクセス.この時Sambaのバージョンは4.5.9であり,CVE-2017-7494という脆弱性をついて,コンテナ内のシェルを取得する.
Sambaコンテナは特権コンテナとして動作しており,
open_by_handle_at()
によってホストのルートディレクトリを開き,ホスト側のシェルを取得する.*1ホスト側のシェルから機密コンテナにアクセスする.(終)
この演習環境のポイント
この演習環境には以下のような脆弱なポイントがあります.
コンテナセキュリティはコンテナの設定,コンテナ上で動くアプリケーション,さらにコンテナランタイム全てを安全な状態にしなければならないです.その事実をこの演習で理解できるような設計になっていると思います.
ハマった点
ハマりポイント1
シナリオ3でホスト側のシェルを取得した後,単にdocker exec -it [機密コンテナ]
とすると,
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Dockerデーモンはホストでは確実に動いているが,実行が確認できない状態になっています.
これに関しては@mrtc0さんにご相談したところ,ホストのルートディレクトリを開いてはいるものの,名前空間は隔離されている状態になっていることが原因だということがわかりました.
解決策としては,
の2つがまず考えられます.
上のものに関しては簡単に検証できました.下に関して少し詳しく流れを追っていきたいと思います.
まず前提として,Sambaコンテナの他にコンテナを一つ建てて,secret.txt
というファイルを作成しました.
root@vagrant:/home/vagrant# docker run -it centos /bin/bash Unable to find image 'centos:latest' locally latest: Pulling from library/centos 7a0437f04f83: Pull complete Digest: sha256:5528e8b1b1719d34604c87e11dcd1c0a20bedf46e83b5632cdeac91b8c04efc1 Status: Downloaded newer image for centos:latest [root@3da30ba4241f /]# ls bin dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var [root@3da30ba4241f /]# echo 'This is secret.' > secret.txt [root@3da30ba4241f /]# ls bin dev etc home lib lib64 lost+found media mnt opt proc root run sbin secret.txt srv sys tmp usr var
次にSambaコンテナをエクスプロイトしてホスト側のファイルシステムを開き,secret.txt
を探索します.
[root@824a6bc898e9 /]# ./a.out <- コンテナブレイクアウトコード opened 4 # whoami root # pwd / # cd /var/lib/docker # ls buildkit containers image network overlay2 plugins runtimes swarm tmp trust volumes # cd overlay2 # find . -name secret.txt ./ac286ee11f15a8dce9f4303e286fc39317c6074b23559241779863c3017a0884/diff/secret.txt find: failed to read file names from file system at or below '.': No such file or directory # cat ac286ee11f15a8dce9f4303e286fc39317c6074b23559241779863c3017a0884/diff/secret.txt This is secret.
このようにして,secret.txt
を読むことができました.
ハマりポイント2(未解決)
※この問題はまだ解決できていません💦
各攻撃シナリオのステージを独立して検証すると,攻撃が成功することを確認しました.
しかし,連続して攻撃をつなげていくとある点でうまくいかないことがわかりました.具体的には攻撃シナリオの1から2にかけての部分で,直接Sambaコンテナを攻撃した場合,リバースシェルを開くことができたのですが,PC1を介した場合,シェルが開くことができませんでした.
Sambaのログを確認したところ,攻撃時にPC1からのアクセスがあったことを確認できたため,この問題はそれ以降のネットワークのルーティングに関する問題ではないかと予想されます.検証としては,wiresharkなどを用いてパケットを確認することが考えられますが,まだできていません.
まとめ
このようにインターンではコンテナセキュリティを絡めた攻撃シナリオ策定と環境構築を行いました.
日本総研・SMBCのサービスにコンテナを用いたシステムはまだ少ないそうなのですが,これから増えると予想されるため,コンテナセキュリティの啓蒙に多少寄与できるような成果物になったと感じています.
金融機関のセキュリティについて興味を持たれている方はぜひ応募してみてください。報酬(時給)も出ます!
参考
open_by_handle_at(2) でコンテナから Break Out する
Sambaの脆弱性〜CVE-2017-7494をやってみる〜 - まったり技術ブログ