サイバーセキュリティ演習のための攻撃シナリオ策定と環境構築【日本総研インターン】

12月7日から12月18日まで,株式会社日本総合研究所で行われたインターンに参加させて頂きました.

www.jri.co.jp

やったこと

日本総研のセキュリティ統括部というところに配属されて,「サイバーセキュリティ演習のための攻撃シナリオの策定と環境構築」というテーマに取り組みました.

SMBCグループのような金融機関は特にサイバー攻撃の対象になりやすく,そのため普段からセキュリティ演習が行われています.しかし,環境がWindows中心や有名な脆弱性をつくものが多く,多少偏りがあると言えます.そこで私はLinuxの知識が必要となるような演習で,さらにこれから確実に必要となってくるコンテナセキュリティを絡めたものを作成することにしました.

基本的には,まず攻撃手法の選定を行い,それを基にシナリオの策定と環境の構築を行いました.

攻撃シナリオと演習環境

簡易的ではありますが,下図のような環境を想定しました.

f:id:udon-yuya:20201223142046p:plain
想定環境

攻撃者は機密情報コンテナにアクセスすることを最終目的とします.

以下が策定した攻撃シナリオです.

  1. PC1ユーザを攻撃者が用意したWebサイトに誘導し,リバースシェルを開かせるマルウェアをダウンロードさせ,実行させる.

  2. PC1を踏み台にし,内部LANからしかアクセスできないSambaコンテナにアクセス.この時Sambaのバージョンは4.5.9であり,CVE-2017-7494という脆弱性をついて,コンテナ内のシェルを取得する.

  3. Sambaコンテナは特権コンテナとして動作しており,open_by_handle_at() によってホストのルートディレクトリを開き,ホスト側のシェルを取得する.*1

  4. ホスト側のシェルから機密コンテナにアクセスする.(終)

この演習環境のポイント

この演習環境には以下のような脆弱なポイントがあります.

  • PC1ユーザがマルウェアをダウンロードし,実行してしまった.

  • コンテナ上で動作しているSambaが脆弱性を含むバージョンであった.

  • Sambaコンテナが特権コンテナとして動作していた.

コンテナセキュリティはコンテナの設定,コンテナ上で動くアプリケーション,さらにコンテナランタイム全てを安全な状態にしなければならないです.その事実をこの演習で理解できるような設計になっていると思います.

ハマった点

ハマりポイント1

シナリオ3でホスト側のシェルを取得した後,単にdocker exec -it [機密コンテナ]とすると,

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 

Dockerデーモンはホストでは確実に動いているが,実行が確認できない状態になっています.

これに関しては@mrtc0さんにご相談したところ,ホストのルートディレクトリを開いてはいるものの,名前空間は隔離されている状態になっていることが原因だということがわかりました.

解決策としては,

  • $HOME/.ssh/authorized_keys に攻撃者の鍵を配置し,ssh接続する.
  • /var/lib/docker 配下のコンテナのファイルシステムに対して操作を行う

の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をやってみる〜 - まったり技術ブログ

攻撃しながら考えるKubernetesのセキュリティ | CloudNative Days Tokyo 2020

Pivoting - Metasploit Unleashed