ここ2日ほど社会人インターンとしてシステムガーディアンさんにお邪魔させていただいています。
今日の業務の結果を記事にするよう依頼されたので、簡単にまとめてみました。
1. 概要
前回の記事では、主に私に向けてDocker-composeを用いてWordPressの環境を構築する手順が紹介されていましたが、
今回はそれをAWSのEC2インスタンス上に構築し、ELBを上に乗せ、ELBにWAF(Trend Micro Managed Rules for AWS WAF – CMS)を
適用しました。 効果はいかほどなものか、簡単な攻撃をしながら検証していきたいと思います。
実際の構築までの流れはぐちゃぐちゃすぎてとても載せられないです。 ごめんなさい。
2. 攻撃の前に
利用したWordPressのバージョンは5.2.2です。
かなり新しいバージョンなので致命的な脆弱性はまだ見つかっていません。
そのため、簡単な
- SQLインジェクション
- XSS
- 過去のwordpressのに存在した脆弱性
の3つの観点からチェックをしていきます。
CMS向けのWAFとのことなので、脆弱性に関してのフィルタリングルールが多そうなイメージがありますね。
また、WAFでブロックされると白背景に403 Forbiddenと大きな文字が出てくるため、
WAFによる保護の有無がアクセス時にわかりやすいです。
その際、HTTPのレスポンスのServerヘッダが awselb になり、アクセス先のコンテンツが格納されているサーバーではなく、
AWSのロードバランサからきちんとレスポンスが返されます。
それでは、はりきって攻撃していきましょう！
①SQLインジェクション
プレースホルダを使っていない場合に攻撃が通る、ありがちな攻撃文を準備しました。
これをIDとパスワード双方につけ、/wp-login.phpに投げつけてみます。
結果は…
通りませんでした…
普通に貫通しました。 びっくりです。
イマドキのCMSにそんなものが通用するわけがない、とトレンドマイクロに嘲笑われている気分です。
くやしいので、次はXSSの攻撃に移ります。
②XSS
XSSにおいては、コメント欄にXSSを埋め込んでいく、よくありがちなStored XSSを狙っていきます。
攻撃文は非常に単純な
を使用します。 さすがにコメントをPOSTしたらWAFの逆鱗に触れそうな気がします。
これは期待ですね。
結果は…
通りませんでした…
まさかのこれも貫通です。 レスポンスがステータスコード200で帰ってきて、
さらに攻撃文が浄化されているところにに悲しみを感じました。
このあたりで本当にWAFが機能してるのか？って焦りながらAWSの設定を何度も確認することとなりました。
③過去のWordpress脆弱性
WordPress 4.7/4.7.1のコンテンツインジェクションで話題になった脆弱性を用い、検証していきます。
脆弱性に関しての詳しい言及は避けますが、Sucuriのウェブサイトがよく解説してくれています。
今回用いているWordPressのバージョンは異なりますが、うまくいけば、WAFのフィルタに引っ掛かり、
ステータスコード403を返してくれるかもしれません。
検証してみましょう。
REST APIの脆弱性ということでcurlでトライします。
curl -v -k -X POST -H 'Content-Type: application/json' -d '' https://xxxxxxxxxx.com/wp-json/wp/v2/posts/1?id=1hello結果は…
成功です！ 無事に403 Forbiddenと表示される形になっていますね！
ちなみに、WAFを外すとしっかりELBではなく、WordPress側からレスポンスを返してくれます。
やはり、CMS向けのWAFは脆弱性管理に最適化されているということでしょうか。
ネタとして面白そうなので今後個人的に追ってみたいと思います。
3. おわりに
ほどよい温度感で業務を体験させていただくことができました。
業務であまり触れないAWSに関しても久々に触れられて楽しかったです。
システムガーディアンさんではインフラエンジニアを募集中とのことです。
皆様もぜひ訪問されてみてください。
