サイボウズ脆弱性報奨金制度で認定されたSSRF

Sep 13, 2018

2017年11月に開催された「サイボウズバグハンター合宿」への参加を機に、サイボウズの脆弱性報奨金制度に挑戦した。2017年度に認定されたcybozu.com共通管理でのSSRFの詳細をサイボウズと合意の上で開示する。

サイボウズの報奨金制度ではクラウドサービスの本番環境での脆弱性調査が禁止されており、調査希望者には cybozu-dev.com 上で動作する検証環境が提供される。以降の調査は全て検証環境で実施している。

cybozu.com共通管理の概要

サイボウズが企業向けに提供するOfficeやGaroon、kintoneなどのクラウドサービスは、共通のドメイン cybozu.com 上で動作する。各サービスのアカウントやセキュリティ設定などはサービスごとに管理せず、「cybozu.com共通管理」で一元管理する仕様となっている。利用企業の管理者はcybozu.com共通管理から社員のアカウントを発行し、権限などを設定できる。

cybozu.com共通管理では、各サービスから送信されるシステムメールも管理できる。標準設定のシステムメールは [email protected] から送信される。自社のメールアドレスからシステムメールを送信したい場合は、以下のページからSMTPサーバーを設定する。

setting_smtp

SMTPサーバーの設定を保存する際、任意のメールアドレス宛にテストメールを送信できる。不適切な設定によりテストメールの送信が失敗すると、以下のページにエラーが残る。脆弱性はSMTPサーバーの設定処理に存在しており、テストメールのエラーを手がかりに発見した。

error_smtp

SSRFの脆弱性

入力値として受け取ったIPアドレスやURLへサーバー側のアプリケーションがリクエストする処理がある。その際の入力値検証に不備があり、内部ネットワークのホストへのリクエストを偽装される問題がサーバーサイドリクエストフォージェリ（SSRF）である^¹。インターネットからアクセスできない内部ホストのポート開閉を調査されるクロスサイトポートアタック（XSPA）などに悪用される脆弱性である。

システムメールの設定では、テストメールを送信する際にSMTPサーバーへ接続を試みる。サーバー名の入力値検証に不備が存在したためSSRFが可能となった。発見に至るまでの調査を解説していく。

ループバックへの接続

内部ホストへリクエストを偽装するため、サーバー名にループバックを設定してサーバー自身への接続を試みる。サーバー名に localhost を入力すると以下のエラーにより設定を保存できない。

localhost_25

ループバックアドレスである 127.0.0.1 に変更してもエラーは発生する。

127.0.0.1_25

これらのエラーはHTML5やJavaScriptによるブラウザ側での入力値検証ではない。サーバー側でループバックの設定を禁止する入力値検証が実装されている。

IPアドレスの検証不備

特殊用途のIPアドレスをまとめたRFC6890ではループバックアドレスを 127.0.0.0/8 と定義している。そのため 127.0.0.1 だけでなく 127.0.0.2 から 127.255.255.254 までのIPアドレスはループバックとして動作する。サーバー名に 127.0.0.2 を入力するとエラーは発生せず、SMTPサーバーの設定を保存できる。しかしテストメールの送信には失敗し、以下のエラーが履歴に残る。

127.0.0.2_25

「Connection refused」とのエラーから、127.0.0.2:25 との接続は確立できていないが、接続リクエストは送信できていることが読み取れる。ポート番号を変更して 127.0.0.2:22 への接続を試みるとエラーの内容が変化する。

127.0.0.2_22

22番ポートはSSHの標準ポートであるため開いている確率が高い。SSHが動作するポートへSMTPの接続リクエストが送信されたため、適切なレスポンスを受信できず「Read timed out」になったと推測される。HTTPが動作する確率が高い8080番ポートへの接続でも同様のエラーが発生する。

127.0.0.2_8080

これらの挙動から「Connection refused」となるポートは閉じており、「Read timed out」となるポートは開いていると特定できる。本来はアクセスできないはずの内部ホスト（サーバー自身）へリクエストを偽装し、ポート開閉を調査できる状態だった。この挙動は「メールサーバ設定に関する不適切な入力の脆弱性（CyVDB-1687）」として認定された。

同一要因の脆弱性

IPv4アドレスは10進数での表記が一般的だが、8進数や16進数でも表記できる。また 0 のオクテットは省略しても動作に影響はない。そのため 0177.0.0.1 や 0177.00001 のような一般的でない形式のIPアドレスも、127.0.0.1 と同じくループバックアドレスとして解釈される^²。システムメールの設定ではSMTPサーバーとして 127.0.0.1 の設定を禁止しているが、一般的でない形式に変換することで設定できる状態だった。

0177.0.0.1_25 0177.00001_25

この挙動はIPアドレスの「形式」の検証不備であり、CyVDB-1687の原因となったIPアドレスの「用途」の検証不備とは異なる問題だと考える。なぜなら用途の検証不備を修正し 127.0.0.2 を禁止したとしても、形式の検証不備が残れば 0177.0.0.2 を設定できるからである。このような理由から形式の検証不備を別の脆弱性として報告したが、評価は同一要因（重複）であった。評価理由についてサイボウズは「どちらも入力されたIPアドレスを適切に検証していないことが問題である」と述べている。

所感

同一要因となったIPアドレスの「形式」と「用途」の検証不備を両方とも認定してもらうには、一方の不備を先に報告し、修正された検証をもう一方の不備により回避できることを実証すべきだった。しかし2017年度の報奨金制度の提出期限が迫っていたため、両方を同時に報告してしまった。一方の修正を待ってからもう一方を報告していれば、両方とも認定してもらえただろう。ただし修正を待っている間にもう一方を他のバグハンターに報告されてしまうリスクはある。次年度の報奨金制度では方針が変わってしまうリスクも考えられる。同一処理で発見した類似の脆弱性は報告時期を見計らう必要があることを知り、バグバウンティの奥深さを実感した。

記事の公開にあたりサイボウズへCyVDB-1687の開示可否を確認し、脆弱性認定ガイドラインの更新後を条件に開示が許可された。この更新によりサイボウズはXSPAを脆弱性として認定しない方針に変わった。今回のような任意のサーバー名とポート番号を設定できる機能でのSSRFの場合、XSPAの実証だけだと今後は認定されないだろう。より現実的な脅威を示さなければならない。

時系列

2017年12月20日 - SSRFを発見
2017年12月20日 - SSRFをサイボウズへ報告
2018年1月31日 - サイボウズからCVSS 2.7で認定との連絡
2018年3月30日 - サイボウズが脆弱性情報を公開
2018年5月31日 - サイボウズから135,000円が入金
2018年9月4日 - サイボウズがガイドラインを更新

^¹ HackerOneの共同創業者であるJobert Abma氏の考えに従い、内部ネットワークへのリクエスト偽装をSSRFとする。
^² 寺田さんがループバックとして解釈される形式をまとめている。