WordPressプラグイン開発のセキュリティ

はじめに

　WordPress のプラグインを開発するにあたって、脆弱性を作らないためにはどのような点に気を付ける必要があるのかを紹介していきます。

読者対象

主に以下の方を対象に本記事を書いています。

• WordPress プラグイン開発者
• WordPress プラグインの脆弱性を見つけたい方
• 脆弱なWordPress プラグインを開発したい方

プラグイン開発で気を付ける脆弱性

本記事では以下の6つの脆弱性について紹介しています。

1. PHPファイルへの直接アクセス
2. サードパーティライブラリ
3. 権限の検証に不備があるAPIの呼び出し
4. CSRF（Cross-site Request Forgery）
5. XSS（Cross-site scripting）
6. SQL インジェクション

　また、WPScan から「WordPress Plugin Security Testing Cheat Sheet」というセキュリティテストのチートシートが提供されております。
このチートシート内の説明は少し物足りないように見受けられますが、網羅的に脆弱性が紹介されていますので目を通しておくことをオススメします。
github.com

脆弱性種類

　WordPress の特徴が強い脆弱性の順で紹介していきます。

① PHPファイルへの直接アクセス

問題点

　まず WordPress のドキュメントルート以下には誰でもアクセスすることが可能です。

　プラグインのインストール先である 「/wp-content/plugins」配下も例外ではないため、プラグインに含まれるPHPファイルに WordPress 経由でなくとも直接アクセスすることが可能です。

　そのため WordPress 経由でのコード実行を想定している場合に、直接アクセスされることで意図していない処理が行われる恐れがあります。

対策

　直接PHPファイルが呼び出された場合にはエラーを返すようにし、WordPress コード内から呼び出された場合にのみ処理を始めるようにします。

具体的にはPHPファイルの先頭に以下のコードを記述します。

<?php

if ( !defined('ABSPATH') ) {
    die( 'Forbidden' );
}

　定数「ABSPATH」は wp-config.php で定義されることになっているので、WordPress 経由でないと「if より後続の処理が実行されない」ということになります。
直接PHPファイルにアクセスされても処理が行われないようになります。

機密ファイルへの直接アクセス

　似たような特徴を持った脆弱性を1つ紹介します。

　前述しましたがプラグインのディレクトリ配下は誰もがアクセスすることが可能です。

　そのディレクトリにアクセスログや管理操作ログなどの機密情報を保存するプラグインの場合、それらのファイルにアクセスされ、内容が閲覧されてしまう可能性があります。実際にそのような脆弱性が報告されているプラグインも存在しています。

　そこで機密情報を含んだファイルを扱っているプラグインは以下のような実装をすることで内容が閲覧されないように対策されていました。

1. ファイル名に推測されないランダム文字列の利用
   → ファイルにアクセスすることが難しくなる
2. ファイル内容の先頭に<?php exit; ?> と記述し、ファイル名を *.php で保存
   → ファイルにアクセスされても内容が表示されない

   

   このようにすると秘密の情報が読み取られません

　上の対策方法の片方を行えば問題ないと考えられますが、両方やっていた方がより安全かなと思っていたりします。
何かの拍子に 「ディレクトリリスティングが有効状態」や「PHPが実行されずPHPファイルがダウンロードされる状態」になった場合のことを考えて。

② サードパーティライブラリ

問題点

　サードパーティから提供されているプログラムを用いて WordPress プラグインを開発した場合に発生する可能性がある脆弱性です。

事例

　2つ事例を紹介します。

事例① elFinder

　「File Manager」には /wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php に特定のリクエストを送信することで任意のファイルをアップロードすることができるという脆弱性がありました。

　これはライブラリ（elFinder）が WordPress を前提で開発されているものではなく、それを考慮せずにライブラリをディレクトリ配下に配置したのが原因で脆弱性が生じてしまったと考えられます。

https://wpscan.com/vulnerability/10389

　サードパーティライブラリを導入することで脆弱性が生じてしまうのは、ライブラリの導入方法が同様であれば脆弱性も同様に発生する点が特徴です。

　実際に「augmented-reality（脆弱性が修正されず非公開状態）」という WordPress プラグインにも全く同じ脆弱性が発見されています。
攻撃者は、このライブラリを用いているプラグインが他に存在するか確認していることでしょう。

https://wpscan.com/vulnerability/10457

事例② Epsilon Framework

　こちらの事例はプラグインではなくテーマの脆弱性です。

しかし脆弱性が生じた原因は事例1と大きく変わらないです。

　Epsilon Framework を利用している15種のテーマから脆弱性が発見されたというものです。

blog.nintechnet.com

　このことからサードパーティライブラリを利用してWordPressプラグインを開発する場合は、ライブラリ導入時に直接アクセスされたくないファイルは「除外」または「WordPress経由以外ではコードを実行させないように修正」したほうが良いです。
（例：デバッグ用のコードが含まれていそうなテストコード tests/ 配下を削除）

　しかしながらサードパーティーライブラリの中身を見てファイルの必要有無の判断やコードの修正するのは難しいです。

日々のプラグイン脆弱性情報から開発で利用しているライブラリ経由で発生している脆弱性がないかを確認するようにし、該当するようであればパッチを当てる運用でも問題ないと思われます。

対策

　開発プラグイン内で利用しているライブラリに脆弱性が存在していないかを検出する仕組みを導入します。
また、脆弱性が存在している場合は「セキュリティパッチが適用されているライブラリに更新」または「開発プラグインには影響がないことを確認」する必要があります。

③ 権限の検証に不備があるAPI

問題点

　WordPress プラグインは register_rest_route 関数 を用いることで、容易に WordPress サイトに REST API を実装することが可能です。

　その API に権限の検証に不備があったり、そもそも権限の検証をしていないといったことが脆弱性になります。

　脆弱性が悪用されることでプラグインの機能が意図していない第三者によって利用される恐れがあります。（記事の投稿・ユーザアカウントの作成 など）

APIが列挙できる REST API ルートエンドポイント

　サイトの REST API の定義内容は、REST API ルートエンドポイント（?rest_route=/）にアクセスすることで確認できるようになっています。

　この機能はデフォルトで有効になっています。無効にするには、WordPressのコードを修正するか、この機能を無効化するプラグインを導入する必要があります。

　この定義情報は攻撃者にとっては有意義な情報であり無効状態が推奨されますが、普段使う機能でないためにデフォルト（有効）状態なっているサイトが多く見られます。

ルートエンドポイントにアクセスすると定義されているAPI一覧が表示されます

認可処理がないAPI

　REST API のルートエンドポイントから API の定義情報からインストールされているプラグインが確認できることから、プラグインの REST API が攻撃の対象となってしまうことがあります。

　そのため REST API にアクセスされた場合に権限の検証をすることは必須事項です。

　WordPress では権限を検証するために「current_user_can」関数が用意されており、簡単に権限の検証を行えるようになっています。

　current_user_can 関数の詳しい使い方は以下を参照下さい。
current_user_can – WordPress私的マニュアル

　むやみにcurrent_user_can 関数を使えば安全というわけではなく、引数として渡す権限のレベルにも気を付けましょう。 寄稿者アカウントで管理者アカウント用の操作ができるようであれば安全とは言えません。

　権限のレベルについては以下を参照下さい。
LevelとCapability – WordPress私的マニュアル

事例

　権限検証の不備で脆弱性が発生してしますが、「current_user_can」関数を用いることで脆弱性の修正が行われています。

blog.nintechnet.com

権限の不備が起因となった脆弱性の修正内容

対策

　前述した「current_user_can」関数などの現行ユーザの権限を取得し、各APIで正常に処理を続行してよいかを検証します。

④ CSRF（Cross-site Request Forgery）

問題点

　特定のWebアプリケーションフレームワークを用いて開発している場合は自動的にCSRFトークンの検証が行われますが、WordPress の場合は自動的にはCSRFの検証は行われません。

　CSRFトークンの検証はプラグイン開発者自身で実装する必要があります。
実装といってもトークンの検証する wp_verify_nonce 関数が用意されてますので、簡単に実装することができます。

　wp_verify_nonce 関数を用いてトークンの検証する場合に気を付けることがあります。

事例

　以下の記事は「wp_verify_nonce」関数を用いているにも関わらず 25種のテーマで CSRF の脆弱性が発見されたというものです。

blog.nintechnet.com

　1つのパターンを引用し説明します。
とある脆弱なプラグインでは以下のコードでCSRFの対策が行われていました。

if ( isset( $_POST['some-nonce'] ) && ! wp_verify_nonce( $_POST['some-nonce'], 'some-nonce' ) ) {
   exit( 'Potential CSRF attack detected.' );
}

　some-nonceパラメータが CSRF トークンであり、wp_verify_nonce関数を用いてCSRFの検証を行い、検証結果が false の場合に処理を中断するので CSRF 対策ができていそうです。

　しかしこのコードでは some-nonce パラメータが送信されない場合が考慮されていないようです。

some-nonce パラメータが送信されていない場合は isset 部分で false となりトークンの検証が行われずに後続処理が行われてしまいます。

　トークンが送信されない場合はエラーとしたいので最初の条件は ! isset( $_REQUEST['some-nonce'] ) にする必要があります。

　細かい点ではありますが、このような実装は実際のテーマで発見されているので、このようなパターンがあることを頭に置いていた方が良いでしょう。

　このような小さなミスで脆弱性が発生するので、脆弱性を見つけてみたいという方には上の記事は面白いと思います。

対策

　誤ったCSRFトークンだけでなく、CSRFトークンが送信されなかった場合にもにエラーになるように実装する。

⑤ XSS（Cross-site scripting）

問題点

　ユーザの入力値を返すようなプラグインに発生する可能性がある脆弱性です。

　Webアプリケーションフレームワークを用いて開発した場合、ブラウザへの出力する際に自動的にエスケープ（サニタイジング）されるのがほとんどですが、WordPress プラグイン開発では自動的にエスケープされません。

　WordPress ライブラリ開発ではエスケープ漏れの部分があると XSS の脆弱性が発生する可能性があります。

　PHPではhtmlspecialchars関数を用いてエスケープすることができますが、WordPress には表示箇所に応じたエスケープ処理をラップした関数が用意されていますので、それらを用いて開発した方が無難です。

関数名	表示箇所
esc_html	タグ要素内
esc_attr	タグ属性内
esc_url	href属性内（利用できるスキームに制限が掛かるようになります）
esc_js	script 内

対策

　ブラウザに表示する値は「htmlspecialchars」関数などを用いてエスケープ処理します。
（昨今のWebフレームワークではそのあたりは自動的に対策されますが、WordPressプラグイン開発の場合は開発者自身で対策します。）

⑥ SQLインジェクション

問題点

　読み込み、書き込み問わずデータベースにアクセスする必要があるプラグインに発生する可能性がある脆弱性です。

　WordPress にはデフォルトで O/Rマッパー が用意されていないので、プラグインにSQLインジェクションの脆弱性が発見されることがたびたびあります。

対策

対策方法を2つ紹介します。

prepare 関数を用いる

　WordPress はデフォルトで O/Rマッパー を用意されておらず、データベースにアクセスするためには 素のSQL文 をコード内に記述する必要があります。

　セキュリティを意識せずにSQL文を組み立てることで、ユーザが入力した任意の値がSQL文の中に挿入されてしまいます。

　ユーザから入力値をエスケープするために prepare関数 を用いるようにしましょう。

prepare関数 の使い方は以下のページが参考になります。
関数リファレンス/wpdb Class - WordPress Codex 日本語版

　以下の差分はとあるプラグインの SQLインジェクション の修正コミットです。

SQLインジェクションの修正部分

バリデーション を行う

　POST（投稿） ID のような数値が想定されている値については、ユーザからの入力値を int型にキャストする処理をします。
また 数値であることの検証（バリデーション）するようにします。

　実際、prepare関数 を使うような脆弱性の修正ではなく、脆弱性があるパラメータを int型にキャストする 修正がいくつかありました。

まとめ

　本記事で紹介したようにセキュアなWordPressプラグインを開発する場合は、脆弱性を生み出さないことを考えながら開発（コーディング）を行っていく必要があります。
Webアプリケーションフレームワークのように自動的に対策されるような脆弱性は皆無と言ってもよいでしょう。 （その点はレガシーと感じてしまう部分となっていますが・・・。） そのため日々、様々なプラグインで脆弱性が報告されている状態であり、シェアの大きいプラグインであっても、深刻な脆弱性が見つかることも珍しくありません。

　このことからWordPressプラグイン開発者は常にプラグインが攻撃の対象になることを意識しながら開発する必要があります。
たとえリリースしたプラグインの導入数が少なくても脆弱性が発見・報告されるということは当然のようにありますので、利用者が少ないから安全というわけではなりません。

　また、何でもいいから脆弱性を発見したいという方は、WordPress プラグインは脆弱性が生まれやすいかつOSSなので、オススメの領域だと思います。
PHPコードの静的解析で脆弱性を検出するツールも存在しているようです。（試してはいません。）

　今回は WordPress プラグインの特色が強い脆弱性を紹介しましたが、本記事で紹介した脆弱性以外にもプラグインに潜む脆弱性は多々あります。
（例：アップロードファイルの検証が行われずPHPファイルなどのファイルがアップロードが可能になっている 等）

参考

• OWASP WordPressセキュリティ実装ガイドライン （セキュアなWordPressの構築）
• Roles and Capabilities | WordPress.org
• WordPress私的マニュアル – WordPressを使ったサイト作成資料として

更新履歴

• 2020年11月17日 新規作成
• 2020年11月24日 「WordPress Plugin Security Testing Cheat Sheet」のリンク追加

GitHubのCode Scanningを使ってみる

はじめに

　先日GitHubから Code Scanning が正式リリースされました。
github.blog

　一言で表すと「プログラムを検査し、脆弱性を検出する」ツールです。

　今までもこのような静的解析ツールは存在していましたが、GitHubパブリックリポジトリに対してのスキャンは「「「無料」」」なので早速使ってみました。

　対応している言語は C、C++、C#、Java、JavaScript、TypeScript、Python、Go となっています。

本記事でやること

• 意図的に脆弱性を埋め込んだWebアプリケーションのスキャン
• スキャン結果の確認

▼ 本記事で利用したリポジトリです。プルリクに検査結果があります。
github.com

　ちなみにリポジトリメンバー以外は検出された脆弱性の詳細情報を確認することができないようです。

• メンバー からの見え方
  
• メンバー以外 からの見え方
  

環境

　本記事で Java で作成したWebアプリケーションをスキャンしていきます。
Webフレームワークには Spring Boot を利用しています。

Java	AdoptOpenJDK 11.0
Spring Boot	2.3.4

スキャンの実行準備

　Code Scanning を実行には、GitHub Actions を利用することができます。

そのためCode Scanningのワークフロー用ファイルを作成するだけでスキャンを実行することが可能です。

ワークフロー用のYAMLファイルの作成

　スキャンを実行するためには .github/workflows/codeql-analysis.yml ファイルが必要です。
このファイルの作成手順は以下の通りです。

①. パブリックリポジトリ内で、Securityタブ > Set up code scanningボタン

　ちなみにプライベートリポジトリでは Set up code scanning の表示されませんでした。

　（当然ですが）Code Scanning 設定後にプライベートリポジトリに変更してもスキャンできません。

②. Set up this workflowボタン

③. Start commitボタン押下後、.github/workflows/codeql-analysis.yml ファイルが作成されます。

codeql-analysis.ymlファイルの内容

# For most projects, this workflow file will not need changing; you simply need
# to commit it to your repository.
#
# You may wish to alter this file to override the set of languages analyzed,
# or to provide custom queries or build logic.
name: "CodeQL"

on:
  push:
    branches: [master]
  pull_request:
    # The branches below must be a subset of the branches above
    branches: [master]
  schedule:
    - cron: '0 4 * * 0'

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest

    strategy:
      fail-fast: false
      matrix:
        # Override automatic language detection by changing the below list
        # Supported options are ['csharp', 'cpp', 'go', 'java', 'javascript', 'python']
        language: ['java']
        # Learn more...
        # https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#overriding-automatic-language-detection

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2
      with:
        # We must fetch at least the immediate parents so that if this is
        # a pull request then we can checkout the head.
        fetch-depth: 2

    # If this run was triggered by a pull request event, then checkout
    # the head of the pull request instead of the merge commit.
    - run: git checkout HEAD^2
      if: ${{ github.event_name == 'pull_request' }}

    # Initializes the CodeQL tools for scanning.
    - name: Initialize CodeQL
      uses: github/codeql-action/init@v1
      with:
        languages: ${{ matrix.language }}
        # If you wish to specify custom queries, you can do so here or in a config file.
        # By default, queries listed here will override any specified in a config file. 
        # Prefix the list here with "+" to use these queries and those in the config file.
        # queries: ./path/to/local/query, your-org/your-repo/queries@main

    # Autobuild attempts to build any compiled languages  (C/C++, C#, or Java).
    # If this step fails, then you should remove it and run the build manually (see below)
    - name: Autobuild
      uses: github/codeql-action/autobuild@v1

    # ℹ️ Command-line programs to run using the OS shell.
    # 📚 https://git.io/JvXDl

    # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
    #    and modify them (or add more) to build your code if your project
    #    uses a compiled language

    #- run: |
    #   make bootstrap
    #   make release

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v1

エラー発生

　codeql-analysis.ymlの作成時にスキャンが実行されましたが、下記のエラーが発生しました。

  [2020-10-10 18:13:27] [autobuild] Daemon will be stopped at the end of the build stopping after processing
  [2020-10-10 18:13:41] [autobuild] > Task :compileJava FAILED
  [2020-10-10 18:13:41] [autobuild] FAILURE: Build failed with an exception.
  [2020-10-10 18:13:41] [autobuild] * What went wrong:
  [2020-10-10 18:13:41] [autobuild] Execution failed for task ':compileJava'.
  [2020-10-10 18:13:41] [autobuild] > Could not target platform: 'Java SE 11' using tool chain: 'JDK 8 (1.8)'.

　Could not target platform: 'Java SE 11' using tool chain: 'JDK 8 (1.8)'.
とメッセージが表示され、Java 11 に対応させる必要がありそうです。

Java 11 に対応

　エラーを解消するために、codeql-analysis.yml内のstepsに以下を追加します。

    - uses: actions/setup-java@v1
      with:
        java-version: '11'

　これで問題なくスキャンが実行されるようになりました。

スキャン実行

　ここからは実際にアプリケーションに対してスキャンを実行してきます。

　今回利用するアプリケーションは Code Scanning を試すために作成したもので意図的に脆弱性を埋め込んでいます。
試した脆弱性は「SQL Injection」「Insecure Deserialization」「Cross-Site Scripting」の３種です。

　そしてスキャンによって検知された脆弱性が、どのように表示されるのかを確認します。

SQL Injection

　スキャンを実行するために SQL Injectionの脆弱性が含まれたコードのプルリクエスト を作成しました。

　スキャンの結果に ❌ が表示されていることから、何か起きたことが分かります。Detailsを押下しスキャンの詳細を確認してみます。

　スキャン結果 1件の脆弱性が検知された旨の記述があり、脆弱性の概要は Query built from user-controlled sources となっています。

　これで意図的に埋め込んだSQL Injection が Code Scanning によって検知されたことが確認できました。

　脆弱性の詳細を確認するためには Show more details を押下します。

そうすると脆弱性が存在しているコード部分が強調された、脆弱性の詳細画面へ遷移します。

　より詳細に脆弱性について知りたいのであれば、Show more を押下します。すると脆弱性の概要や修正方法、参考リンクなどの情報が展開されます。

　下画像は SQL Injection の場合ですが、結構なボリュームがあります。

　さらにShow pathsを押下すると、ユーザが入力した値（ここではname値）がどのような流れでSQLに挿入されるのかを確認できます。（親切すぎる！）

Insecure Deserialization（安全でないデシリアライゼーション）

　次は Insecure Deserialization の脆弱性を埋め込んでスキャン してみます。

　スキャン結果の詳細は以下のように表示されました。

　Insecure Deserialization でも同様にユーザが入力した値がどのような流れで脆弱なコードにたどり着くのかを確認することができました。

Cross-Site Scripting（XSS）

　最後に Cross-Site Scripting（XSS） の脆弱性を埋め込んでスキャン してみます。

　スキャン結果から先に言うと、Code Scanning では脆弱性が検知されませんでした。

　脆弱性を含むプルリクエストは下画像です。上部がコントローラ側、下部がビュー側となっています。

　XSSの原因となっているコードは <span th:utext="${msg}"/> の部分で th:utext を使っている点です。 これはユーザから与えられた値はHTMLエスケープせずに表示されるようになっています。

　ですが、下画像のスキャン結果通り XSS は検知されませんでした。

　原因は不明ですが、Javaコード外で発生している脆弱性だからなのではないかなと思っています。
(テンプレートエンジンは検査対象外？)
　それか 脆弱性の埋め込み力 が足りていない・・・。

その他

リポジトリにアクティビティがないと無効化される

　Code Scanning を有効化しているリポジトリは60日間更新しないと自動的に無効化されるようです。

　無効化される前に下のようなメールが届きました。

　メール記載のリンク先からすぐに更新することができました。

まとめ

　今回初めて GitHub の Code Scanning を利用してみましたが、導入が簡単であり、検出された脆弱性についても説明や検出理由の記載もあり、有意義な機能だと感じました。

　パブリックリポジトリでの利用は無料ですので、今後の開発では導入するのが一般的になっていくのではないかと期待していまが、どうしてもプライベートリポジトリでの利用は有償となっているので、その点が導入のハードルになるのではと思っています。

　プライベートリポジトリで利用するためには、「GitHub One」ライセンス、または「Enterprise + Code scanning オプション」ライセンス を利用する必要があるとのことです。

　価格は提示されていませんが、十分な機能が提供されていることもありますのでいいお値段しそうです。

　今も様々な言語がサポートしていますが PHP や Ruby もサポートされることに期待しています。

更新履歴

• 2020年10月11日 新規作成

【WordPress】CVE-2020-25286 "最近のコメント"から保護されているコメントの閲覧可能

はじめに

　本記事では先日(2020/9/13)に公表された WordPress 本体の脆弱性である CVE-2020-25286 について簡単に調べてみました。

　まずNVDには CVE-2020-25286 について下記の説明があります。

In wp-includes/comment-template.php in WordPress before 5.4.2, comments from a post or page could sometimes be seen in the latest comments even if the post or page was not public.

　この説明から「公開されていない記事・固定ページのコメントが閲覧される脆弱性」であることが分かります。

　本記事では、どのような条件下で脆弱性が再現するのかを確認していきます。

CVSS 3.1 (Base Score: 5.3)

　ちなみに本脆弱性の CVSS はこのような評価となっています。

　システムへの影響は 機密性 のみです。
漏れる可能性があるのはコメントだけですので 低 と評価されています。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

攻撃元区分(AV：Attack Vector)	ネットワーク(N)
攻撃条件の複雑さ(AC：Attack Complexity)	低(L)
必要な特権レベル(PR：Privileges Required)	不要(N)
ユーザ関与レベル(UI：User Interaction)	不要(N)
スコープ(S：Scope)	変更なし(U)
機密性への影響(C：Confidentiality Impact)	低(L)
完全性への影響(I：Integrity Impact)	なし(N)
可用性への影響(A：Availability Impact)	なし(N)

脆弱性の確認

　検証で利用する WordPress のバージョンは 5.4.1 です。ちなみに修正版は 5.4.2 です。

下準備

　WordPress 5.4.1 を下記のサイトからダウンロードし、展開します。 Release Archive | WordPress.org 日本語

　WordPressの自動更新を無効化するために、ディレクトリ直下にあるwp-config.phpを開き下記の一行を追加します。
この設定がないと自動的に修正版にアップデートされてしまいます。

define( 'AUTOMATIC_UPDATER_DISABLED', true );

　そしてサイトにアクセスし、初期設定（DB設定、管理ユーザ設定、サイト設定）を完了させます。

脆弱性の再現手順

　ここからは脆弱性を再現させるために、「パスワード保護された記事（= 公開されていない記事）の作成」と「その記事に対してのコメント書き込み」を行っていきます。

1. パスワード保護の記事を作成

　管理者アカウントでパスワード保護された記事を作成します。
「秘密の記事」というタイトルで作成します。

　右サイドバーからパスワード保護の有無の設定ができますので、「表示状態：パスワード保護」の状態で公開します。

2. 【攻撃】パスワード保護された記事へコメントを書き込み

　「1.」で作成した記事へアクセスして、パスワードを入力する必要があることも確認します。

　パスワードを入力して、記事が表示されたらコメントを書き込みます。

　「⚠️これは秘密記事へのコメントです⚠️」とコメントを書き込みました。
このコメントはパスワードを知っている人のみが閲覧できるものです。脆弱性が再現することでこのコメントが誰でも見れる状態になってしまいます。

3. 未認証ユーザでコメントの確認

　次は、未認証のユーザでパスワード保護された記事へアクセスしてみます。

　このユーザはパスワードを知らない前提ですので、記事を表示させることもできなく、「2.」で書き込んだコメントも閲覧することはできません。

この脆弱性は このようなパスワード保護されたコメントが表示されてしまう脆弱性 となっていますが、どこに表示されるのでしょうか？

　NVD の説明にこの記載があり、"最新のコメント"部分に表示されることが分かります。

seen in the latest comments

　"最新のコメント"は下部のウィジットに表示されるはずだったので確認してみます。

　しかし、公開されている記事と共にコメントの内容の表示はありませんでした。

4. 「最新のコメント」ブロックを追加

　少し調べてみると記事本文中に「最新のコメント」ブロックを追加できることが判明したので、このブロックを公開記事である「Hello world!」というタイトルに追加します。

　この記事は公開記事なので誰でも記事の内容を閲覧することができます。

　追加するとした下画像のようになりました。

　先ほど確認した"最新のコメント"と異なりコメントの内容も表示されていることが分かります。

　この状態で公開します。

5. 【被害の確認】未認証ユーザでコメントの確認

　未認証ユーザで先ほど編集した「Hello world!」へアクセスします。
前にも記載しましたが、この記事は誰でも内容を閲覧することができます。

　記事の内容には最近のコメントの一覧が表示されるようになっており、その中にはパスワード保護された記事に書き込んだコメントの内容も表示されてしまっています。
(⚠️これは秘密記事へのコメントです⚠️という内容が見れてしまっています)

　脆弱性があることでこの事象が再現しました。

　最後にパッチを当ててこの事象が再現しないことを確認します。

6. 修正版にアップデード

　パッチを当てるために、Wordpressを現時点の最新版(5.5.1)にアップデートします。

　アップデートが完了したら、再度未認証ユーザで先ほどの記事にアクセスし、コメントの内容を閲覧できるか確認してみます。

　パスワード保護された記事のコメントには「パスワード保護」と表示されるようになり、元のコメントが閲覧できなく脆弱性は修正されたことが確認できました。

　この脆弱性の修正内容を確認してみても、パスワード保護されている記事のコメントはダミーテキストを表示するようにしていることからこの挙動は正しそうです。

まとめ

　一覧に表示される情報にも気を配る。普段目にしないような機能なら見逃し注意。
今回のWordPressに限らず、一覧を表示するプラグインなどを利用する場合は意図していなかった情報が表示される挙動があるかもしれないと頭に入れていた方がいいかも。

　本脆弱性は、普段使われない機能(埋め込み「最新のコメント」) + 最新5件(デフォルト) なので、影響を受ける可能性は非常に少ないと思ってたり。

参考

• NVD - CVE-2020-25286
• Changeset 47984 – WordPress Trac

更新履歴

• 2020年9月29日 新規作成

インシデント対応ツール『GRR Rapid Response』【YARA編】

Yaraといったら「Passion Yara」

はじめに

　GRR Rapid Response (以下GRR)について軽く説明、GRR はGoogleが開発しているインシデント対応ツールであり、主にフォレンジックを行うために利用されます。

　このツールの特徴としては、フォレンジック対象(GRRクライアント)のサーバにログインすることなく、GRRサーバからフォレンジックを実施することが可能です。
　GRRクライアントを増やす場合は、対象サーバにエージェントをインストールするだけで完了です。

　前回はこのツールを利用して、プロセス情報やブラウザの閲覧履歴の取得を行いました。
今回はGRRドキュメントに「YARA」の記載がありましたので、この機能を試してみます。

　ドキュメントには以下の説明があり、GRRのYARA機能にはプロセスメモリの解析ができそうです。

Live remote memory analysis using YARA library.

　GRRの導入はこちらを参照ください。
blog.motikan2010.com

インシデント対応ツール『GRR Rapid Response』【構築編】

GRR Rapid Response とは？

　「GRR Rapid Response」（以下、GRR）はGoogleが開発しているインシデントレスポンス時にするツールであり、主にフォレンジック作業を支援するツールです。

　このツールの特徴として、フォレンジック対象の端末にログインすることなく、フォレンジック作業を行うことができます。

　そのため、事前にフォレンジック対象端末にはGRRエージェントがインストールされている必要があります。

▼ イメージ図

What is GRR? — GRR documentation

GRR クライアントの機能

• クライアントは Linux、OS X、Windows に対応
• YARAライブラリを使用したライブリモートメモリフォレンジック
• 「ファイル」と「Windowsレジストリ」の強力な検索やダウンロード機能
• SleuthKit（TSK）を使用したOSレベルおよびrawファイルシステムアクセス
• インターネット展開用に設計された安全な通信インフラストラクチャ
• クライアントのCPU、メモリ、IOの使用状況、および自分で課した制限の詳細な監視

GRR サーバの機能

• ほとんどのインシデント対応およびフォレンジックタスクを処理する、完全な対応機能
• エンタープライズハンティング（一連のマシン全体の検索）のサポート
• 何百ものデジタルフォレンジックアーティファクトの高速でシンプルなコレクション
• AngularJS Web UIとRESTful JSON API、Python、PowerShell、Goのクライアントライブラリ
• さまざまなフォーマットや出力プラグインをサポートするデータエクスポート機能
• 大規模なデプロイメントを処理できる完全にスケーラブルなバックエンド
• スケジューリングによるタスクの自動実行
• 多数のラップトップで動作するように設計された、クライアントの将来のタスクスケジューリングを可能にする非同期設計

GRRの開発リポジトリ

　GRR Rapid Response はOSSであり、コードはGItHubで管理されています。

github.com

環境構築

　では実際に動作確認を行うためにGRRの環境構築を行っていきます。

　以下のように役割が異なる２つのサーバ（仮想環境）を構築します。

• フォレンジック対象である「GRR クライアント」
• フォレンジックに必要な情報を取得する「GRR サーバ」

　今回はGRRクライアントは１台で作業を進めていきます。

環境の概要

　GRRサーバはUbuntu上に構築してきます。

　GRRクライアントも同様にUbuntu上に導入します。
GRRクライアントでサポートされているOSは以下の３です。

• Windows
• Mac OS
• Linux OS

　今回の検証で利用する各ソフトウェアのバージョンは以下の通りです。

VirtualBox	6.1.12
Ubuntu	18.04.3
GRR Rapid Response	3.4.2

　「VirtualBox」と「Ubuntu」のバージョンに関しては最近のものであればなんでもいいと思います。

GRR サーバの構築

▼debパッケージを使用したインストールマニュアル
grr-doc.readthedocs.io

MySQL インストール

　GRRサーバを動作させるためにはMySQLが必要です。

　インストールと一緒に「専用ユーザの作成」と「DBの作成」を行います。

# MySQLのインストール
$ sudo apt install -y mysql-server

# ユーザ・DBを作成
$ sudo mysql -u root -p
> SET GLOBAL max_allowed_packet=41943040;
> CREATE USER 'grr'@'localhost' IDENTIFIED BY 'grr_pass';
> CREATE DATABASE grr;
> GRANT ALL ON grr.* TO 'grr'@'localhost';

# 確認
$ sudo mysql -u'grr' -p'grr_pass' -e 'show databases'

GRR Rapid Response インストール

　debパッケージをダウンロードして、インストールします。

$ wget https://storage.googleapis.com/releases.grr-response.com/grr-server_3.4.2-0_amd64.deb
$ sudo apt install -y ./grr-server_3.4.2-0_amd64.deb

　インストール中にDBの認証情報やGRRサーバの情報などの設定項目が聞かれます。
今回はメールについての機能は使用しない想定ですので、メール関連の設定はスキップ（デフォルト設定）しています。

　設定内容は設定ファイルに保存されますので、後で変更することも容易です。

Step 0: Importing Configuration from previous installation.
No old config file found.

Step 1: Setting Basic Configuration Parameters
We are now going to configure the server using a bunch of questions.
Use Fleetspeak (next generation communication framework)? [yN]:  [N]:【✅ Enter】


-=GRR Datastore=-
For GRR to work each GRR server has to be able to communicate with
the datastore. To do this we need to configure a datastore.

GRR will use MySQL as its database backend. Enter connection details:
MySQL Host [localhost]:【✅ Enter】
MySQL Port (0 for local socket) [0]: 3306  ✅ MySQLのポート番号
MySQL Database [grr]:【✅ Enter】
MySQL Username [root]: grr  ✅ 先ほど作成したDBユーザ
Please enter password for database user grr:【✅ Enter】
Configure SSL connections for MySQL? [yN]:  [N]:【✅ Enter】
Successfully connected to MySQL with the provided details.


-=GRR URLs=-
For GRR to work each client has to be able to communicate with the
server. To do this we normally need a public dns name or IP address
to communicate with. In the standard configuration this will be used
to host both the client facing server and the admin user interface.

Please enter your hostname e.g. grr.example.com [user1-VirtualBox]: 192.168.56.15  ✅ ホストOSからもアクセスするのでゲストOSのIP


-=Server URL=-
The Server URL specifies the URL that the clients will connect to
communicate with the server. For best results this should be publicly
accessible. By default this will be port 8080 with the URL ending in /control.

Frontend URL [http://192.168.56.15:8080/]:【✅ Enter】


-=AdminUI URL=-:
The UI URL specifies where the Administrative Web Interface can be found.

AdminUI URL [http://192.168.56.15:8000]:【✅ Enter】


-=GRR Emails=-
GRR needs to be able to send emails for various logging and
alerting functions. The email domain will be appended to GRR
usernames when sending emails to users.



-=Monitoring/Email Domain=-
Emails concerning alerts or updates must be sent to this domain.

Email Domain e.g example.com [localhost]:【✅ Enter】


-=Alert Email Address=-
Address where monitoring events get sent, e.g. crashed clients,
broken server, etc.

Alert Email Address [grr-monitoring@localhost]:【✅ Enter】


-=Emergency Email Address=-
Address where high priority events such as an emergency ACL bypass are sent.

Emergency Access Email Address [grr-emergency@localhost]:【✅ Enter】

Step 2: Key Generation
All keys will have a bit length of 2048.
Generating executable signing key
Generating CA keys
Generating Server keys
Generating secret key for csrf protection.

Writing configuration to /etc/grr//server.local.yaml.
I0909 13:16:27.637845 139789273700160 config_lib.py:470] Writing back configuration to file /etc/grr//server.local.yaml
Initializing the datastore.
I0909 13:16:27.812390 139789273700160 server_logging.py:186] Writing log file to /usr/share/grr-server/lib/python3.6/site-packages/grr_response_core/var/log//GRRlog.txt

Step 3: Adding GRR Admin User
Please enter password for user 'admin':【✅ 管理者パスワートの登録（Webダッシュボードにログインするために必要）】

Step 4: Repackaging clients with new configuration.
Server debs include client templates. Re-download templates? [yN]:  [N]:【✅ Enter】
Repack client templates? [Yn]:  [Y]:【✅ Enter】

（略）

GRR Initialization complete! You can edit the new configuration in /etc/grr//server.local.yaml.

Please restart the service for the new configuration to take effect.

#################################################################
Install complete.
If upgrading, make sure you read the release notes:
https://grr-doc.readthedocs.io/en/latest/release-notes.html
#################################################################
Processing triggers for libc-bin (2.27-3ubuntu1) ...

　これでGRRサーバの構築が完了しました。

　ちなみに設定ファイルは「/etc/grr/server.local.yaml」にあります。
このファイルを編集することで先ほど設定した内容を変更することができます。

　以下が設定ファイルの中身です。

$ sudo cat /etc/grr/server.local.yaml
Database.implementation: MysqlDB
Blobstore.implementation: DbBlobStore
Mysql.host: localhost
Mysql.port: 3306
Mysql.database: grr
Mysql.database_name: grr
Mysql.username: grr
Mysql.database_username: grr
Mysql.password: grr_pass
Mysql.database_password: grr_pass
Client.server_urls:
- http://192.168.56.15:8080/
Frontend.bind_port: 8080
AdminUI.url: http://192.168.56.15:8000
AdminUI.port: 8000
Logging.domain: localhost
Monitoring.alert_email: grr-monitoring@localhost
Monitoring.emergency_access_email: grr-emergency@localhost
PrivateKeys.executable_signing_private_key: '-----BEGIN RSA PRIVATE KEY-----

（以下略）

GRRサーバの起動の確認

　念のためGRRサーバが起動していることの確認。

$ sudo systemctl status grr-server
● grr-server.service - GRR Service
   Loaded: loaded (/lib/systemd/system/grr-server.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2020-09-09 13:14:50 JST; 7min ago
     Docs: https://github.com/google/grr
  Process: 30748 ExecStart=/bin/systemctl --no-block start grr-server@admin_ui.service grr-server@frontend.service grr-server@worker.service grr-server@worker2.service fleetspeak-server.service (code=exit
 Main PID: 30748 (code=exited, status=0/SUCCESS)

 9月 09 13:14:50 user1-VirtualBox systemd[1]: Starting GRR Service...
 9月 09 13:14:50 user1-VirtualBox systemd[1]: Started GRR Service.

　動いているっぽい。

GRRクライアントの導入

　次はフォレンジック対象端末にGRRクライアントを導入します。

　GRRサーバに比べるとGRRクライアントの導入は簡単です。

▼ debパッケージを使用したエージェント導入マニュアル
grr-doc.readthedocs.io

エージェント（debパッケージ）の取得・インストール

　まずはエージェントをダウンロードするために、GRRサーバのダッシュボート(http://192.168.56.15:8000)にアクセスします。

　ダッシュボードにログインするための認証情報はGRRサーバのインストール中に設定したものです。

　トップページは以下のようになります。

　左サイドバーの「Binaries」を押下することで、各環境のエージェントが表示されます。
debパッケージからインストールするので、deb拡張子のファイルを押下してダウンロードします。

　 あとは以下の手順をするだけです。

# ゲストOS側へdebファイルをコピー
$ scp grr_3.4.2.0_amd64.deb user2@192.168.56.16:/tmp/

# エージェントをインストール
$ cd /tmp/
$ sudo dpkg -i grr_3.4.2.0_amd64.deb

　これでクライアント側へのエージェントの導入は完了です。
特に設定も必要ありません。

エージェントの起動の確認

　念のためエージェントが起動していることの確認。

$ sudo systemctl status grr
● grr.service - grr linux amd64
   Loaded: loaded (/lib/systemd/system/grr.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-09-09 13:57:41 JST; 1min 52s ago
 Main PID: 5501 (grrd)
    Tasks: 6 (limit: 2332)
   CGroup: /system.slice/grr.service
           ├─5501 /usr/lib/grr/grr_3.4.2.0_amd64/grrd --config=/usr/lib/grr/grr_3.4.2.0_amd64/grrd.ya
           └─5502 /usr/lib/grr/grr_3.4.2.0_amd64/grrd --config=/usr/lib/grr/grr_3.4.2.0_amd64/grrd.ya

 9月 09 13:57:41 user2-VirtualBox systemd[1]: Started grr linux amd64.
 9月 09 13:57:43 user2-VirtualBox grrd[5501]: I0909 13:57:43.106781 140121068840768 client_logging.py

　こちらも動いているっぽいです。

動作確認

　GRRに馴染みのない方が多いと思われるので、キャプチャ画像を使って説明していきます。

　まずは、先ほどエージェントをインストールしたGRRクライアント情報を見てみます。

　ダッシュボート上部の「虫眼鏡ボタン」を押下します。左のテキストエリアは空白でよいです。

　GRRクライアント一覧が表示されます。
今回は１台のサーバにしか導入していないので、１行のみ表示されています。

　該当のサーバの行を押下すると、そのサーバの詳細ページに遷移します。

　OS、NWインタフェースの情報などが表示されました。

　もちろんGRRこちらに表示された情報よりも有意義な情報を取得することができます。

　今回は例として「該当サーバでListenしているプロセス一覧」と「指定ユーザのWebブラウザ閲覧履歴」の２パターンを見てみます。

Listenしているプロセス一覧の取得

　左サイドバーの「Start new flows」→ 「Processes - ListProcesses」を開きます。

この画面ではクライアントのプロセス情報を取得することができます。

　今回は Listenしているプロセス一覧 を取得するので、 Connection states に「LISTEN」を選択します。
選択後は、「Launch」ボタンを押下してください。

　下の画面でしばらく待ちます...。上部の通知ボタンが赤くなったら、取得処理が完了したことを表します。
赤くなったボタンを押下します。

　そうすると今までの取得処理の一覧が表示されいます。
私の画面では何回か取得処理を動かしたので複数表示されています。

　一番上のものが最新の取得処理なので先ほど動作させたものなります。
「4 results」と記載されているため、プロセス情報の取得処理は成功していることが分かります。

　プロセスの詳細も確認したいので、取得処理の部分（赤枠）を押下します。

　プロセスの詳細が表示されました。
画面には１つのプロセス情報しか収めていませんが、４つプロセス情報が表示されています。

　対象のサーバでは80番ポートが動作しているようです。
記述していませんが、裏でncコマンドで80番ポートをListenしていました。

　Pidも取得できたので、メモリダンプも取得できそうです。
ですが、今回はさわりだけですので、そこまでは行いません。

　念のためGRRクライアントに入ってListenしているプロセス見てみます。

４つプロセスが表示されており、Web上で確認した情報は正しそうです。

ブラウザの閲覧履歴を取得

　次は趣向を変えてユーザのブラウザの閲覧履歴を取得してみることにします。

　左サイドバーの「Start new flows」 → 「Browser - FirefoxHistory」を開きます。

　この画面ではFirefoxブラウザの閲覧履歴を取得することができます。

　試しに「user2」のブラウザの閲覧履歴を取得してみます。

　取得結果は以下のようになっています。
「cat+image」のような文字列があることから、user2は猫の画像をググったことが確認されました。

　このように特定のサーバだけではなく、人が利用するシステム（今回はWebブラウザ）の痕跡なども確認できるようになっています。

本記事では２種類の機能しか紹介できませんでしたが、他にもさまざまな項目を遠隔地から確認できるようになっています。

まとめ

　今回初めて「GRR Rapid Response」をさわってみました。
クライアントを導入したサーバが１台ということもあり、そこまでこのツールの恩恵を授かることはできていなかったと思っております。

　導入することが本記事のメインであったため、様々な機能にさわることができていないのが残念ですが、機能項目を見てみたところまだまだ楽しそうな機能がたくさんありました。
　次はクライアントの台数を増やしたり、別のOSのクライアントで試したりしたいと思っております。

本格的なフォレンジック機能もあると思いますので、その辺りもさわっていく予定です。

　とはいっても『〇〇編』と銘打って続きを書いたことが(ry

　続きを書きました。YARAが使えるとのこと。
blog.motikan2010.com

更新履歴

• 2020年9月10日 新規作成
• 2020年9月11日 YARA編のリンク追加

『不信なPoCは実行するな』というお話【セキュリティ】

はじめに ~ 脆弱性PoCの収集リポジトリ ~

　私は脆弱性のPoCが自動的に収集しているリポジトリを公開していますが、先日このようなIssueが作成されました。

そのIssueの内容を端的に言うと「収集しているPoCにマルウェアが混ざってるでボケェ！！」というもの。

正体はマルウェアだったリポジトリ

　ここでは「CVE-2020-0883」「CVE-2020-0910」の2つの脆弱性があげられており、それぞれ「thelostworldFree/CVE-2020-0883」「inetshell/CVE-2020-0910」リポジトリのことを指していると考えられます。

　実際にこの2つのリポジトリ内のコードを確認してみます。異なる脆弱性のPoCですが、Pythonコードがほぼ同じであり非常に怪しいリポジトリであることが分かります。

　そのコードの詳細はテンセント社のブログで紹介されていたのでそちらを参照ください。（中国語ですが・・・）

上記の2つとは別の脆弱性(CVE-2020-0796 : Microsoft SMBv3の脆弱性)で説明されていますが、コードの動作内容は同じなので問題ないです。

cloud.tencent.com

　（※以下、Google翻訳を駆使して理解できた内容です。）
　この記事を簡単に説明すると、

・この怪しいコードは実行時に指定した「検査対象となるホスト」情報を54[.]184[.]20[.]69に送信するような動作したそうです。
・そして送信されたホスト情報に対して外部かSMBパケットが送信されたそうです。

　明らかに脆弱性検証コードの動作ではなく、黒なコードであったことが確認できます。

まとめ ~ 無闇にPoCを実行してはイカン!! ~

　つまり何が言いたいかというと、信用できないPoCを安易に実行してはいけないということです。
今エンジニアとして働いている私にとっては当然のことではありますが、学生の頃は適当に見つけたPoCを実行するようなことがありました。（不思議と.exe等の実行ファイルは怪しんでいましたが...）
そんなPoCの内容を一切確認しない人を標的としているんでしょうね。

　そんな感じでPoCを実行するときは、コードをしっかり確認した方がいいよという記事でした。

軽くコードを見るだけでも分かる場合がほとんどです（今回の様に不明な難読化をしていたり）。
ちなみにコードを読んでもよく分からん時はとりあえず実行しないようにしています（or 死んでもいい環境で動かしたり）。

　下画像のようにIssue内で「このリポジトリが怪しい」ということを教えてくれる場合もあるようです。

　感覚的となりますが、他PoCリポジトリよりスター数が多いリポジトリは正当なPoCリポジトリと判断して良さそうです。

更新履歴

• 2020年5月26日 新規作成

【Azure】Azure CLIでApplication Gateway WAFを操作 - カスタムルール編

はじめに

　本記事では Application Gateway WAF のポリシーやカスタムルールの制御(作成・削除など)を azコマンド経由で実行する方法を説明します。

Azure CLI(azコマンド)で Application Gateway WAF を操作

1. WAFポリシー

$ az network application-gateway waf-policy -h

Group
    az network application-gateway waf-policy : Manage application gateway web application firewall
    (WAF) policies.

Subgroups:
    custom-rule    : Manage application gateway web application firewall (WAF) policy custom rules.
    managed-rule   : Manage managed rules of a waf-policy. Visit: https://docs.microsoft.com/en-
                     us/azure/web-application-firewall/afds/afds-overview.
    policy-setting : Defines contents of a web application firewall global configuration.

Commands:
    create         : Create an application gateway WAF policy.
    delete         : Delete an application gateway WAF policy.
    list           : List application gateway WAF policies.
    show           : Get the details of an application gateway WAF policy.
    update         : Update an application gateway WAF policy.
    wait           : Place the CLI in a waiting state until a condition of the application gateway
                     WAF policy is met.

1-1. WAFポリシーの作成 (create サブコマンド)

　createサブコマンドのヘルプ

$ az network application-gateway waf-policy create -h

Command
    az network application-gateway waf-policy create : Create an application gateway WAF policy.

Arguments
    --name -n           [Required] : The name of the application gateway WAF policy.
    --resource-group -g [Required] : Name of resource group. You can configure the default group
                                     using `az configure --defaults group=<name>`.
    --location -l                  : Location. Values from: `az account list-locations`. You can
                                     configure the default location using `az configure --defaults
                                     location=<location>`.
    --tags                         : Space-separated tags: key[=value] [key[=value] ...]. Use '' to
                                     clear existing tags.

Examples
    Create an application gateway WAF policy. (autogenerated)
        az network application-gateway waf-policy create --name MyApplicationGatewayWAFPolicy
        --resource-group MyResourceGroup

$ az network application-gateway waf-policy create \
--name TestPolicy \
--resource-group testResourceGroup

1-2. WAFポリシーの詳細表示 (show サブコマンド)

　showサブコマンドのヘルプ

$ az network application-gateway waf-policy show \
  --resource-group 'testResourceGroup' \
  --name 'TestPolicy'

----- 出力 -----
{
  "applicationGateways": null,
  "customRules": [],
  "etag": "W/\"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\"",
  "httpListeners": null,
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/TestPolicy",
  "location": "japaneast",
  "managedRules": {
    "exclusions": [],
    "managedRuleSets": [
      {
        "ruleGroupOverrides": [],
        "ruleSetType": "OWASP",
        "ruleSetVersion": "3.0"
      }
    ]
  },
  "name": "TestPolicy",
  "pathBasedRules": null,
  "policySettings": {
    "fileUploadLimitInMb": 100,
    "maxRequestBodySizeInKb": 128,
    "mode": "Detection",
    "requestBodyCheck": true,
    "state": "Disabled"
  },
  "provisioningState": "Succeeded",
  "resourceGroup": "testResourceGroup",
  "resourceState": null,
  "tags": null,
  "type": "Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies"
}
---------------

2. カスタムルール

$ az network application-gateway waf-policy custom-rule -h

Group
    az network application-gateway waf-policy custom-rule : Manage application gateway web
    application firewall (WAF) policy custom rules.

Subgroups:
    match-condition : Manage application gateway web application firewall (WAF) policies.

Commands:
    create          : Create an application gateway WAF policy custom rule.
    delete          : Delete an application gateway WAF policy custom rule.
    list            : List application gateway WAF policy custom rules.
    show            : Get the details of an application gateway WAF policy custom rule.
    update          : Update an application gateway WAF policy custom rule.

2-1. カスタムルールの作成 (create サブコマンド)

　createサブコマンドのヘルプ

$ az network application-gateway waf-policy custom-rule create -h

Command
    az network application-gateway waf-policy custom-rule create : Create an application gateway WAF
    policy custom rule.

Arguments
    --action            [Required] : Action to take.  Allowed values: Allow, Block, Log.
    --name -n           [Required] : Name of the WAF policy rule.
    --policy-name       [Required] : The name of the application gateway WAF policy.
    --priority          [Required] : Rule priority. Lower values are evaluated prior to higher
                                     values.
    --resource-group -g [Required] : Name of resource group. You can configure the default group
                                     using `az configure --defaults group=<name>`.
    --rule-type         [Required] : Type of rule.  Allowed values: Invalid, MatchRule.

　ポリシー「TestPolicy」にカスタムルール「TestCustomRule」を作成。

$ az network application-gateway waf-policy custom-rule create \
  --action 'Block' \
  --name 'TestCustomRule' \
  --policy-name 'TestPolicy' \
  --priority '50' \
  --resource-group 'testResourceGroup' \
  --rule-type 'MatchRule'

----- 出力 -----
{
  "action": "Block",
  "etag": null,
  "matchConditions": [],
  "name": "TestCustomRule",
  "priority": 50,
  "ruleType": "MatchRule",
  "skippedManagedRuleSets": []
}
---------------

2-2. カスタムルールの削除 (delete サブコマンド)

　deleteサブコマンドのヘルプ

$ az network application-gateway waf-policy custom-rule delete -h

Command
    az network application-gateway waf-policy custom-rule delete : Delete an application gateway WAF
    policy custom rule.

Arguments

Resource Id Arguments
    --ids               : One or more resource IDs (space-delimited). It should be a complete
                          resource ID containing all information of 'Resource Id' arguments. If
                          provided, no other 'Resource Id' arguments should be specified.
    --name -n           : Name of the WAF policy rule.
    --policy-name       : The name of the application gateway WAF policy.
    --resource-group -g : Name of resource group. You can configure the default group using `az
                          configure --defaults group=<name>`.
    --subscription      : Name or ID of subscription. You can configure the default subscription
                          using `az account set -s NAME_OR_ID`.

　リソースグループ「testResourceGroup」のポリシー「TestPolicy」内のカスタムルール「TestCustomRule」を削除。

$ az network application-gateway waf-policy custom-rule delete \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy' \
  --name 'TestCustomRule'

2-3. カスタムルールの一覧 (list サブコマンド)

　listサブコマンドのヘルプ

$ az network application-gateway waf-policy custom-rule list \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy'

----- 出力 -----
[
  {
    "action": "Block",
    "etag": null,
    "matchConditions": [
      {
        "matchValues": [
          "hoge",
          "fuga"
        ],
        "matchVariables": [
          {
            "selector": null,
            "variableName": "QueryString"
          },
          {
            "selector": null,
            "variableName": "PostArgs"
          }
        ],
        "negationConditon": false,
        "operator": "Contains",
        "transforms": [
          "Lowercase",
          "RemoveNulls"
        ]
      }
    ],
    "name": "TestCustomRule",
    "priority": 50,
    "ruleType": "MatchRule",
    "skippedManagedRuleSets": []
  }
]
---------------

2-4. カスタムルールの詳細 (show サブコマンド)

　カスタムルールを指定して詳細を確認することができます。

　showサブコマンドのヘルプ

$ az network application-gateway waf-policy show -h

Command
    az network application-gateway waf-policy show : Get the details of an application gateway WAF
    policy.

Arguments

Resource Id Arguments
    --ids               : One or more resource IDs (space-delimited). It should be a complete
                          resource ID containing all information of 'Resource Id' arguments. If
                          provided, no other 'Resource Id' arguments should be specified.
    --name -n           : The name of the application gateway WAF policy.
    --resource-group -g : Name of resource group. You can configure the default group using `az
                          configure --defaults group=<name>`.
    --subscription      : Name or ID of subscription. You can configure the default subscription
                          using `az account set -s NAME_OR_ID`.

Global Arguments
    --debug             : Increase logging verbosity to show all debug logs.
    --help -h           : Show this help message and exit.
    --only-show-errors  : Only show errors, suppressing warnings.
    --output -o         : Output format.  Allowed values: json, jsonc, none, table, tsv, yaml,
                          yamlc.  Default: json.
    --query             : JMESPath query string. See http://jmespath.org/ for more information and
                          examples.
    --verbose           : Increase logging verbosity. Use --debug for full debug logs.

Examples
    Get the details of an application gateway WAF policy. (autogenerated)
        az network application-gateway waf-policy show --name MyApplicationGatewayWAFPolicy
        --resource-group MyResourceGroup

　カスタムルール「TestCustomRule」の詳細を出力してみます。

$ az network application-gateway waf-policy custom-rule show \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy' \
  --name 'TestCustomRule'

----- 出力 -----
{
  "action": "Block",
  "etag": null,
  "matchConditions": [
    {
      "matchValues": [
        "hoge",
        "fuga"
      ],
      "matchVariables": [
        {
          "selector": null,
          "variableName": "QueryString"
        },
        {
          "selector": null,
          "variableName": "PostArgs"
        }
      ],
      "negationConditon": false,
      "operator": "Contains",
      "transforms": [
        "Lowercase",
        "RemoveNulls"
      ]
    }
  ],
  "name": "TestCustomRule",
  "priority": 50,
  "ruleType": "MatchRule",
  "skippedManagedRuleSets": []
}
--------------------

2-5. カスタムルールの更新 (update サブコマンド)

$ az network application-gateway waf-policy custom-rule update -h

Command
    az network application-gateway waf-policy custom-rule update : Update an application gateway WAF
    policy custom rule.

Arguments
    --action            : Action to take.  Allowed values: Allow, Block, Log.
    --priority          : Rule priority. Lower values are evaluated prior to higher values.
    --rule-type         : Type of rule.  Allowed values: Invalid, MatchRule.

Generic Update Arguments
    --add               : Add an object to a list of objects by specifying a path and key value
                          pairs.  Example: --add property.listProperty <key=value, string or JSON
                          string>.
    --force-string      : When using 'set' or 'add', preserve string literals instead of attempting
                          to convert to JSON.
    --remove            : Remove a property or an element from a list.  Example: --remove
                          property.list <indexToRemove> OR --remove propertyToRemove.
    --set               : Update an object by specifying a property path and value to set.  Example:
                          --set property1.property2=<value>.

Resource Id Arguments
    --ids               : One or more resource IDs (space-delimited). It should be a complete
                          resource ID containing all information of 'Resource Id' arguments. If
                          provided, no other 'Resource Id' arguments should be specified.
    --name -n           : Name of the WAF policy rule.
    --policy-name       : The name of the application gateway WAF policy.
    --resource-group -g : Name of resource group. You can configure the default group using `az
                          configure --defaults group=<name>`.
    --subscription      : Name or ID of subscription. You can configure the default subscription
                          using `az account set -s NAME_OR_ID`.

3. マッチ条件

$ az network application-gateway waf-policy custom-rule match-condition -h

Group
    az network application-gateway waf-policy custom-rule match-condition : Manage application
    gateway web application firewall (WAF) policies.

Commands:
    add    : A match condition to an application gateway WAF policy custom rule.
    list   : List application gateway WAF policy custom rule match conditions.
    remove : Remove a match condition from an application gateway WAF policy custom rule.

3-1. マッチ条件を追加 (add サブコマンド)

$ az network application-gateway waf-policy custom-rule match-condition add -h

Command
    az network application-gateway waf-policy custom-rule match-condition add : A match condition to
    an application gateway WAF policy custom rule.

Arguments
    --match-variables [Required] : Space-separated list of variables to use when matching. Variable
                                   values: RemoteAddr, RequestMethod, QueryString, PostArgs,
                                   RequestUri, RequestHeaders, RequestBody, RequestCookies.
    --operator        [Required] : Operator for matching.  Allowed values: BeginsWith, Contains,
                                   EndsWith, Equal, GeoMatch, GreaterThan, GreaterThanOrEqual,
                                   IPMatch, LessThan, LessThanOrEqual, Regex.
    --values          [Required] : Space-separated list of values to match.
    --negate                     : Match the negative of the condition.  Allowed values: false,
                                   true.
    --transforms                 : Space-separated list of transforms to apply when matching.
                                   Allowed values: HtmlEntityDecode, Lowercase, RemoveNulls, Trim,
                                   UrlDecode, UrlEncode.

Resource Id Arguments
    --ids                        : One or more resource IDs (space-delimited). It should be a
                                   complete resource ID containing all information of 'Resource Id'
                                   arguments. If provided, no other 'Resource Id' arguments should
                                   be specified.
    --name -n                    : Name of the WAF policy rule.
    --policy-name                : The name of the application gateway WAF policy.
    --resource-group -g          : Name of resource group. You can configure the default group using
                                   `az configure --defaults group=<name>`.
    --subscription               : Name or ID of subscription. You can configure the default
                                   subscription using `az account set -s NAME_OR_ID`.

　実際に以下の表のマッチ条件を作成してみます。

マッチ条件
Match variable	["QueryString", "PostArgs"]
Operator	"Contains"
Match values	["hoge", "fuga"]
Transformations	["Lowercase", "RemoveNulls"]

$ az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy' \
  --name 'TestCustomRule' \
  --match-variables 'QueryString' 'PostArgs' \
  --operator 'Contains' \
  --values 'hoge' 'fuga' \
  --transforms 'Lowercase' 'RemoveNulls'

-----  出力 -----
{
  "matchValues": [
    "hoge",
    "fuga"
  ],
  "matchVariables": [
    {
      "selector": null,
      "variableName": "QueryString"
    },
    {
      "selector": null,
      "variableName": "PostArgs"
    }
  ],
  "negationConditon": null,
  "operator": "Contains",
  "transforms": [
    "Lowercase",
    "RemoveNulls"
  ]
}
---------------

　Azureのダッシュボード から作成されたことが確認できました。

3-2. マッチ条件の一覧 (list サブコマンド)

$ az network application-gateway waf-policy custom-rule match-condition list \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy' \
  --name 'TestCustomRule'

----- 出力 -----
[
  {
    "matchValues": [
      "hoge",
      "fuga"
    ],
    "matchVariables": [
      {
        "selector": null,
        "variableName": "QueryString"
      },
      {
        "selector": null,
        "variableName": "PostArgs"
      }
    ],
    "negationConditon": false,
    "operator": "Contains",
    "transforms": [
      "Lowercase",
      "RemoveNulls"
    ]
  }
]
---------------

3-3. マッチ条件を削除 (remove サブコマンド)

$ az network application-gateway waf-policy custom-rule match-condition remove -h

Command
    az network application-gateway waf-policy custom-rule match-condition remove : Remove a match
    condition from an application gateway WAF policy custom rule.

Arguments
    --index  [Required] : Index of the match condition to remove.

Resource Id Arguments
    --ids               : One or more resource IDs (space-delimited). It should be a complete
                          resource ID containing all information of 'Resource Id' arguments. If
                          provided, no other 'Resource Id' arguments should be specified.
    --name -n           : Name of the WAF policy rule.
    --policy-name       : The name of the application gateway WAF policy.
    --resource-group -g : Name of resource group. You can configure the default group using `az
                          configure --defaults group=<name>`.
    --subscription      : Name or ID of subscription. You can configure the default subscription
                          using `az account set -s NAME_OR_ID`.

$ az network application-gateway waf-policy custom-rule match-condition remove \
  --resource-group 'testResourceGroup' \
  --policy-name 'TestPolicy' \
  --name 'TestCustomRule' \
  --index 0

Githubスターが100超えたから紹介【セキュリティ】

はじめに

　先日私が作成したGitHubリポジトリのスター数が100を超えました！圧倒的感謝！(-人-)謝謝

100個を超えたことに気づいている様子が以下のツイートです。

起きたらスター100超えてた。初の3ケタスターということで非常にうれしい。 pic.twitter.com/fqBush9wvz

— モチカン (@motikan2010) March 2, 2020

ちなみに記念すべき100個目のスターは自分で付けようと思っていましたが、就寝中であったため付けられませんでした。(¦3ꇤ[▓▓]

　そして本記事ではこのリポジトリがどのようリポジトリであるのかを紹介します。

　ついでに私が管理しているセキュリティ関連のリポジトリもいくつか紹介します！（＋α 私自身のリポジトリ参照頻度でオススメ度も記載します）

　日々セキュリティ情報を収集している方にはきっと役に立つはずです。

「PoC-in-GitHub」とはどのようなリポジトリ? [ オススメ度：★★★☆ ]

　下のリポジトリがそれです。

github.com

　一言でリポジトリを説明すると、
　　　　Github上にある脆弱性PoC(Proof of Concept)のリポジトリが列挙されている
　となります。

　収集の仕組みとしては、GitHub API で「CVE-1999- ~CVE-2020-」を自動的に検索してそれをまとめているだけです。

仕組みは単純ですが、数時間前に作成されたPoCに気づくこともあるのでなかなか便利です。
（Forkしている人はなんなんだろ・・・）

その他リポジトリも紹介させて！

　上記リポジトリのように セキュリティ情報 を自動的に収集してまとめているリポジトリは他にも3つあるので紹介します。

NVD情報を保存している「NVD-Database」 [ オススメ度：★☆☆☆ ]

github.com

　NVD情報をダウンロードして格納しているリポジトリです。
このようなリポジトリは他に結構存在しているので説明は割愛。

　作成当初は定期的に内容を確認しようと考えていましたが、追記・変更量的が多すぎるので１度もまともに確認したことないです。

CVEをリスト化している「CVE-Easy-List」 [ オススメ度：★★★★ ]

　CVE情報を収集している CVEProject/cvelist をリスト化しているリポジトリです。
ステータスが PUBLIC となってCVEのみをリスト化しており、昨日パブリックになったCVEを確認したい時などに重宝しています。

github.com

　Github上のDIFFで確認するようにしており、新規にパブリックになった脆弱性は一目瞭然です。(もちろんCVE-IDが未採番の脆弱性は載っていないです)

　頻繁に確認するようにしているリポジトリです。皆さんは直近に公開されたCVE情報を確認するとき、どのようにしているんでしょうね？

CVEのExploitがリスト化されている「NVD-Exploit-List-Ja」 [ オススメ度：★★☆☆ ]

github.com

　NVD内には Exploit タグが付いているリンクがあります。それらのリンクをリスト化しているリポジトリです。

　JVN(Japan Vulnerability Notes)の情報も用いており、JVNに存在するCVEに関しては日本語の説明を表示するようにしています。

　以上、紹介したのがセキュリティ情報を収集しているリポジトリです。

まだ4つしかないので、今後もいろいろ作成していく予定です。直近ではCVE IDが採番されていない脆弱性を収集したリポジトリを作成する予定です。

おまけ

裏方アカウント

　紹介したリポジトリを管理しているアカウントです。

　GitHubには「無料アカウントを複数個所有してはいけない」という有名な利用規約があるので、このアカウントを作成時にメインアカウントを有料プランに移行したりしました。

　自動で情報を追記しているので管理しているので草生えまくりです。この草の状態が死活監視対象となっていたり。
コミットの草を見てみると 平日の草が濃い ようにみえる。やはり休日の脆弱性の更新は減り気味なのかね？

脆弱性をリスト化することによる副作用

　脆弱性がCVE単位で詳細に管理されているサイトとして Vulmon があります。

　このようなサイトには脆弱性の詳細情報が記載されているサイトへのリンクが当然のように存在しています。

　詳細情報には脆弱性の詳細情報が記載されているGitHubへのリンクも含まれていますが、脆弱性の詳細が記載されていない私のリポジトリへのリンクもあったりします。(自動収集だからかと考えられます)

　荒らしているような感じがして、罪悪感があったりなかったり・・・。

まとめ

一旦紹介はこんな感じです。

　これらのリポジトリは私自身が便利だと感じており、どこかのタイミングで紹介しようと考えていましたので、スター数が100個というキリ良いタイミングで紹介できてよかったです。

　本来は50個で紹介記事を書こうと思っていました。そのタイミングを逃した時は次のキリのよいタイミングは100個ということで、いつになることやらと思っていましたが、結構早めに迎えることができうれしいです。

　余談として、私はスターが増える毎に過敏に反応しており、スターを付けたアカウントをチェックしていたりします。
それらのアカウントのプロフィールをみる限り中国語圏の方がほどんどで、中国圏の方々は脆弱性情報好きすぎだとと気づいた次第です。

　次は情報を集めたリポジトリではなく、ライブラリなどのプログラムでスターを集めてみたい。

更新履歴

• 2020年3月5日 新規作成

【Webセキュリティ】Apache Dubbo の脆弱性をやる(CVE-2019-17564)

はじめに

　2020年2月10日にApache Dubbo の脆弱性が公表されました。
CVE-2019-17564が登録されたのは2019年10月14日のようです。

　本脆弱性の内容を一言で言うと、「安全でないデシリアライゼーションのJava版」です。

　こちらのメールにて Dubboプロジェクトチーム に対して本脆弱性が伝えられています。
https://www.mail-archive.com/dev@dubbo.apache.org/msg06225.html

　CVE STALKER のデイリーランキングでは7位になっています。

【Python】Waitress の ReDoS をやってみる(CVE-2020-5236)

いらすとや産のPython

はじめに

　GitHub Advisory Database - CVE-2020-5236 で 緊急度が Critical(最も危険) となっていたので調べてみました。

GitHub アドバイザリ - CVE-2020-5236

　影響を受ける Waitress のバージョンは1.4.2のみです。
リリースのタイムラインは以下のようになっています。2020年1月中に導入した人はバージョンを確認してみたほうがよいでしょう。(※本脆弱性以外にも過去のバージョンには他の脆弱性が見つかっているようでした。)

• 1.4.2 2020年 1月 2日 リリース
• 1.4.3 2020年 2月 2日 リリース

Waitress — waitress 1.4.3 documentation

Waitress とは

　あまり耳にしないソフトウェアだと思う「Waitress」は何かと言うと、「WSGI サーバ」らしい。

　WSGI サーバとは何ぞやというと、

Web Server Gateway Interface (WSGI; ウィスキー) は、プログラミング言語Pythonにおいて、WebサーバとWebアプリケーション（もしくはWebアプリケーションフレームワーク）を接続するための、標準化されたインタフェース定義である。

by Wikipedia

つまり、
　　Django や Bottle といったPython言語のWebアプリケーションフレームを動作させる為のアプリケーションサーバとのこと。
　Ruby界隈で例えると Unicorn に近い役割を持っているWebサーバだと思う。

　WSGI サーバーについてのより詳しい内容は以下の記事が参考になりました。
WSGIアプリケーションとは？WebフレームワークからWSGIサーバーまで - Make組ブログ

　今回脆弱性が発見された「Waitress」はそのようなソフトウェアの1つということです。

　どのくらい普及しているのかというと、GitHub の 約12,800個のリポジトリで利用されていることから、そこそこ普及しているWebサーバだと思います。

2020/2/5 現在

　そんな Waitress から ReDoS(Regular expression Denial of Service) の脆弱性が発見されました。
本脆弱性の再現には特別な設定等は必要なく、さらに攻撃方法が容易ということで簡単に再現してしまうことから緊急度が Critical となっていると思います。

github.com

【Webセキュリティ】依存ライブラリのセキュリティチェックツール(SCA)を使ってみる

はじめに

　まず「依存ライブラリのセキュリティチェックツール」とは？ということですが、このようなツールの呼び方が定まっていないため本記事ではこのような呼び方にしています。
（強いて言えば、Software Composition Analysツールと呼ばれているツール群）

これらのツールの特徴として、動作しているアプリケーションが依存しているライブラリやパッケージに既知の脆弱性が存在していないかをバージョン情報などをもとに検査します。脆弱性があるバージョンのライブラリがあるとアラートを出す挙動をします。

　従来から利用されている Burp Suite や OWASP ZAP などのWebセキュリティ診断ツールは実際にアプリケーションを動作させて、その挙動から脆弱性を検出します。それに対して「依存ライブラリのセキュリティチェックツール」はアプリケーションを動作させずに検査します。ツールの動作が全く異なるので、検査内容も大きく違います。

　どちらかといったらWordPressの検査に利用される WPScan に検査内容は近いです。どちらも利用しているプラグイン(ライブラリ)のバージョン情報で検出するのがメインとなっているからです。
それでも検査を実施できる範囲は異なります。
　WPScan はネット越しに公開されているサイト全てに検査することが可能です。対して「依存ライブラリのセキュリティチェックツール」はアプリケーションが依存しているライブラリが記述されているファイル（Gemfile.lock や composer.lock）が検査対象になりますので、それらのファイルを閲覧できる権限者のみが検査を実施できます。それらのファイルに依存関係はほぼ全て記述されているので、依存関係を全て取得するのが難しいネット越しでの検査に比べてより厳密な検査ができます。

　そして近頃、Webアプリケーションなどのソフトウェアに依存しているライブラリに既知の脆弱性が潜んでいないかを検査するために、セキュリティチェックツールを提供・利用するサービスが増えてきている気がしています。

▼ Snyk もセキュリティチェックツールを開発/提供している企業であり資金調達が上手くいっている模様。 jp.techcrunch.com

　まずは、手軽に導入することができるOSSのセキュリティチェックツールを使用してみて、どのような検査結果を得ることができるのかなどを確認してみます。
ついでに検出された脆弱性の情報はどこから取得しているのかなども確認してきます。

2018年 人気脆弱性 TOP 10 in GitHub

はじめに

　2020年 1発目の投稿となりますが、時代に逆行して2018年に人気だった脆弱性を紹介します。
先日書いた「2019年 人気脆弱性 TOP 10 in GitHub」の2018年版です。

↓ 2019年版 ↓
blog.motikan2010.com

TOP 10

　TOP 10の算出方法としては、「リポジトリの数」と「それらのリポジトリのスターの数」を使用しています。
リポジトリ毎に10ポイント、スター毎に1ポイント 加算される形式で算出しています。
　※各脆弱性のタイトルはJVNから引用しています。

10位 541 ポイント 『Intel Core マイクロプロセッサを搭載したシステムにおける情報漏えいに関する脆弱性(CVE-2018-3620 通称「Foreshadow」)』

access.redhat.com

人気リポジトリ
GitHub - ionescu007/SpecuCheck: SpecuCheck is a Windows utility for checking the state of the software mitigations and hardware against CVE-2017-5754 (Meltdown), CVE-2017-5715 (Spectre v2), CVE-2018-3260 (Foreshadow), and CVE-2018-3639 (Spectre v4)