【ICTSC7】 URAの問題解説
問題文
とある顧客からD社が運営しているECサイトへ繋がらないと連絡があった。調べた結果、悪意のあるものから攻撃を受けてしまった痕跡があり、即座に外部との通信を遮断した。
その後、ECサイト開発者が脆弱性を発見し修正を行ったが、攻撃の被害が残っている。
攻撃を受ける前の状態にECサイトを復旧させ、対策を行い、原因を究明して報告してほしい。
ログイン情報
host |
user |
pass |
sudo |
p19.problem.ictsc |
admin |
Ny3jaubP |
yes |
MySQLのログイン情報は以下の通りである。
報告を行う際は以下の例を参考にして記述してほしい。
今回のテーマ
- MySQL Serverの脆弱性(CVE-2016-6662)
- 攻撃者の行動をApache HTTP Server(
/var/log/httpd/*
)やMySQL Serverのクエリーログ(/tmp/query.log
)から推測してもらいたい
- 適切な報告書を記述できるかの技術を見極めたい
CVE-2016-6662
- mysqld_safeがrootで起動して, mysqldがmysqlに落として起動される
- mysqld_safeのset_malloc_lib()でshared library がMySQL Serverを起動する前に読み込まれて,
--malloc-lib=LIB
へセットされる
- 設定ファイルを書き換えられるので, この変数で読み込む値を
my.cnf
の[mysqld]か[mysqld_safe]セクションで好きに設定できるということ
- mysqld_safeで実行しているので, 任意の任意コードがmysqlサーバ起動時にroot権限で実行される
- とにかくヤバヤバな脆弱性である(そもそもSQLインジェクションできる時点でアレ)
採点基準
- /etc/mysql/my.cnfから書き換えられた設定項目を削除する(20%)
-
/etc/mysql/my.cnfの所有者と権限を変更する(20%)
- 攻撃した箇所を削除しただけでは再度攻撃される恐れがある
- 再発防止を行うためには所有者を
root
にし、実行権限を0750
に設定し、MySQL Serverから書き込めないように設定を行うことが重要である
- MySQL ServerのrootユーザーのFILE権限を落とすことが出来れば加点をあげる
-
ECサイトが利用しているデータベースの復旧(30%)
/tmp/query.log
にMySQLのクエリーログが記載されているが、よく見るとECサイトの管理アカウントのパスワードが変更されている
- このままではWeb GUIからログインされてしまい二次被害が出るので, MySQL Clientを利用し, 管理アカウントのパスワードを別のものに変更する必要がある
-
原因究明(30%)
- 回答テンプレートを元に記述してもらう
- 報告書として正しく記述出来ているかを中心に採点を行なった
- 模範回答(詳細は省く)
- 攻撃者はECサイトの管理画面(http://p19.problem.ictsc/admin)のログインフォームにSQLインジェクションを行った
- 書き換えられた部分は
my.cnf
内の[mysql]部分とECサイトの管理者アカウントのパスワード(攻撃者は1234に設定したようである)
- 攻撃元のIPアドレスはApacheの
access_log
やerror_log
から172.16.16.10であることが判明
- 今回用いたSQLインジェクションは,
my.cnf
内に直接書き込めたことからCVE-2016-6662であることが判明
- 適切な対処法としては,
my.cnf
の所有者と権限を変更し, MySQLのrootユーザーのFILE権限を落とし, 攻撃者が書き換えたECサイトの管理者パスワードを任意の文字列に再設定した
- そのほか, ECサイトにはクロスサイトスクリプティングが出来る脆弱性が残っているため, その部分を正しく報告出来れば加点をあげた(残念ながら回答できたチームはいなかった)
講評
- 15チーム中, 基準点を満たしたチームは3チームであった(前問のTABを通過出来たチームは6チーム)
- 参加者に楽しんでもらえるようにECサイトのデザインなどを工夫してみたが, 喜んでもらえたようである
- 問題の難易度的にはやや難しめであったようだ(次回の課題点)
- ログは宝箱である(ここ重要)