Sophos Cloud Optix
Transport Layer Security (TLS) は、最近のオンラインサイバーセキュリティにおいて重要な役割を果たしています。
TLS とはデータ保護プロトコルのことで、ブラウザのアドレスバーに南京錠を表示したり (通信が SSL 化されていることを示します)、電子メールの送信時に暗号化を行ったり、サイバー犯罪者がダウンロードしたソフトウェアをマルウェアなどの悪意のあるファイルで置き換えてしまうのを防ぐのに利用されています。
TLS プロトコルは以下の仕組みによって動作します。
- 接続先と一回限りの暗号化キーを設定することで、データを覗き見や監視から守ります。
- 接続先サーバーの運営者や会社を確認することで、悪意を持った人物が偽のサイトを作って訪問者を騙すことを防ぎます。
- 届いたデータの整合性をチェックすることで、ネットワーク上の他の人物が途中でコンテンツを改ざんすることを防ぎます。
TLS は非常に大きな役割を果たしていることから、脆弱性が発見されると、通常大きなニュースになります。
面白いことに、上記のような TLS への関心の高さはある種の宣伝効果をもたらしており研究者たちは発見した TLS の脆弱性に、報道の興味を引くような名前やロゴを意図的につけています。
これらの脆弱性は冗談めかして「BWAIN」と呼ばれます。これは「bug with an impressive name (印象的な名前を持つバグ)」を略した呼称で、過去には「BEAST」、「Heartbleed」、「Logjam」、「Lucky Thirteen」などがありました。
今回の記事で取り上げる 「ALPACA」もその一例です。
攻撃の重大さに比して控えめな脅威
幸いにも、ALPACA はそれほど便利な攻撃ではなく、いくつかの簡単な方法によりサーバー上で (すなわち、間接的には訪問者に対しても) この攻撃が発生するのを防ぐことができます。ですので、現在オンラインコマースにとって明確な危険があるわけではありません。
しかしながら、ALPACA は脆弱性、より正確には脆弱性群です。このような脆弱性は、インターネット社会全体が TLS を使用するサーバーの設定時に注意深く、または厳密でなかったために発生します。
TLS 証明書の使いまわし
ALPACA は Application Layer Protocols Allowing Cross-Protocol Attacks (クロスプロトコル攻撃を可能にするアプリケーションレイヤープロトコル) の略であり (多くの BWAIN はこのような言葉遊びを含んでいます)、TLS の接続が特定のアプリケーションに結びついておらず、代わりに特定のアプリケーションや目的に制限されないトランザクション内のデータを保護するだけであることからこのような名前がついています。
研究者たちは、現存する何百万ものネットワークドメインが、HTTP (Web ブラウジング) と SMTP (電子メール転送) の両方を保護するなど、複数の異なる目的のため複数のサーバーで TLS を使用しているにも関わらず、提供するサービスごとに TLS プロセスの検証部分を分離していないことが多くあることを発見しました。
言い換えると、たとえばメールサーバーを他のメールサーバーとの間で検証するために使用しているのと同じ TLS 証明書が、ブラウザを使用する訪問者に対して Web サーバーを検証するためにも使えるということです。
つまり、(一見複雑で現実味のないようなことに思えますが) たとえば攻撃者が閲覧者のブラウザを企業の Web サイトから電子メール (または secure FTP、IMAP、POP3) サーバーのうちの一つにリダイレクトさせた場合、閲覧者のブラウザはその疑わしいサーバーを代わりに信頼してしまう可能性があるということです。
攻撃者はサーバーに直接侵入できなくても、ネットワーク内でトラフィックのリダイレクトを行うことができる場合もあります。
ALPACA 攻撃は、単にサービスの中断や停止を引き起こすだけではなく、トラフィックリダイレクトを使用してネットワーク内外のセキュリティを侵害することもあります。
問題は、TLS は保護している接続を介して転送されるローデータを保護し、接続を要求されたサーバーの名前を検証する反面、リンクの両端で実行されている実際のアプリケーションを正式に検証したり、交換されているデータの信頼性を判断しないことです。
つまり、ALPACA 攻撃では、ブラウザのアドレスバーに南京錠マークが表示されるので、訪問者は本来意図したサーバーに接続されていないことに気づかないまま、ブラウザがネットワーク上の別のサーバーを信頼して通信を開始するのです。
問題点
しかし、ブラウザが用いるプロトコルは HTTP である一方、メールサーバーが用いるのは SMTP です。この 2 つには互換性がなく、一見ブラウザにエラーメッセージが表示されるだけで済むように思われるかもしれません。
しかし、ALPACA の研究者たちは、サーバーの種類によって、認識するエラーのタイプおよびエラーに対する防御方法が異なってプログラムされているという問題を発見しました。
たとえば、Web サーバーは (当然のことですが) Web リクエストに返信する際、返信に含まれるデータがどのように表示されるかに非常に注意を払っています。
たとえば、ある Web サイトの検索リンクをクリックした際、そのリンクに <script>alert('Ooops!')</script> のような検索パラメータが含まれていた場合には Web サーバーはその部分を除いた Web ページを返信しなければなりません。
仮にサーバーが「Sorry, the text <script>alert('Ooops!')</script> was not found」のような返信をしたとすると、これは信頼できない第三者が作成した JavaScript を含む Web ページを、サーバーが自身を配信元として認証を与えて提供したことになります。
この攻撃は XSS またはクロスサイトスクリプティングとして知られています。(より正確には、反射型 XSS と呼ばれるもので、サーバーは特定の JavaScript をブラウザにそのまま反映し、ブラウザはほぼ自動的に反映された JavaScript を信頼して実行します。
ちなみに、上の段落の JavaScript タグを含むように見える部分は、実際のテキストをそのまま画面に表示しているわけではありません。本 Web ページには JavaScript タグをそのまま表示することなく、適切な場所に配置するようブラウザに指示する HTML コードが使用されています。
重大なセキュリティホール
XSS は重大な Web セキュリティホールです。なぜなら、反映されたスクリプトは現在アクセスしているサイト固有のログインクッキーなどのデータにアクセスし、ログイン情報を盗んだり、不正な商取引を行ったり、業務を妨害することができるからです。
一方、メールサーバーは普通 JavaScript を扱うことはなく、メール送信アプリケーションが解読できる形で返信をするようになっています。そのため、ブラウザからメールサーバーに宛てて細工された偽の Web リクエストを送信すると、
メールサーバーからの返信の中に、Web サーバーで行われるような綿密な XSS チェックを経ていないエラーメッセージが含まれる可能性があります。
しかし、メールサーバーが不正に反映された JavaScript を送り返してきたとしても、それが何の問題になるのかと思われるかもしれません。電子メールサーバーとセッションクッキーやショッピングカート、その他のプライベートな Web データは関連付けられておらず、攻撃者はそれ以上何もできないように思われます。
ただし、例外が一つ存在します。ブラウザは本物の Web サーバーに接続していると認識していますが、その認識がなされたのは実際に本物の Web サーバーに接続した場合に有効な TLS 証明書が提示されたからです。
したがって、悪意のないメールサーバーによって反射された不正なスクリプトにより、ブラウザが実際には Web サーバーに全く接続していないにも関わらず、ブラウザのクッキーや Web サーバーに関連する Web データが読み取られることがあります。
サーバーの混同
しかし、そもそもなぜブラウザは Web サーバーの TLS 証明書とメールサーバーの証明書を混同してしまうのでしょうか。
Let’s Encrypt のような証明書発行会社が登場し、TLS 証明書を無料で簡単に取得できるようになるまでは、ネットワーク上のすべてのサーバーの証明書を購入・更新するのにかなりの手間 (とコスト) がかかっていました。
その結果、企業は当然ネットワークドメイン内の複数台、あるいはすべてのサーバーに対して有効な証明書を用いることが多くなります。
たとえば、www.example.com と mail.example.com のそれぞれに対して別々の証明書を取得する代わりに、*.example.com に対して有効な、いわゆるワイルドカード証明書を使用することができます。このアスタリスクは「任意の文字列」を意味し、多くのファイル検索プログラムが、「*.DOCX」を「.DOCX という拡張子を持つ全てのファイル」のことだと判断するのと同じ仕組みです。
非常に簡略化されてはいますが、これこそが、ALPACA 問題の本質です。
ネットワーク上の複数の異なる種類のサーバーに対して有効な TLS 証明書は、ALPACA の CA、すなわちクロスプロトコル攻撃 (Cross-protocol Attacks) を行うために使用することができます。
ブラウザは確かに誤ったサーバーを信用してしまい、誤った方式で通信をしてしまいますが、攻撃者はサーバー自体を直接ハッキングしなくとも、ある種の有害なセキュリティバイパスを行うことができるのです。
対策
研究者たちは、ネットワークへの訪問者が不審な ALPACA 攻撃に騙されないよう、TLS の悪用のリスクを減らすためのいくつかの方法を明らかにしています。
- 1. アプリケーション単位での対策を行うこと。
ネットワークプログラマーの間で有名な、故 late Jon Postel 氏がインターネットの黎明期に提唱した、「堅牢性原則 (Robustness Principle)」</emと呼ばれる言葉があります。「TCP の実装は堅牢性の一般原則に従うべきである。送信するものに関しては厳密に、受信するものに関しては寛容に」というものです。
しかし、この「ルール」を現代に適用するのは危険であり、時代遅れです。というのも、このルールはプログラマー自身がセキュリティについて詳しく、および正しく理解することを促す一方で、他の人がおそらく故意に、そして悪意をもってルールを破ることを認容してしまうからです。
より時代に即したルールは「自らは正しいことを行い、意図によらず、他人に間違ったことをさせない」となるでしょう。
たとえば、Postfix の SMTP サーバーは、コマンドのスペルミスだけでなく、HTTP リクエストの開始のように見える SMTP をプロアクティブに (指示がなくとも) 監視し、Web ブラウザと通信していると判断した場合にはすぐに接続を閉じます。
$ mailcat mail.example 25 [connected, type commands after -->] <-- 220 mail.example ESMTP Postfix --> RSET -- legal SMTP command <-- 250 2.0.0 Ok -- expected reply --> RESET -- harmlessly mis-spelled command <-- 502 5.5.2 Error: command not recognized --> GET / HTTP/1.1 -- potentially dangerous HTTP command <-- 221 2.7.0 Error: I can break rules, too. Goodbye. [connection closed] -- Postfix treats this as GAME OVER $ mailcat mail.example 25 [connected, type commands after -->] <-- 220 mail.example ESMTP Postfix --> QUITE -- mis-typing of QUIT, error is tolerated <-- 502 5.5.2 Error: command not recognized --> Connection: close -- illegal in SMTP, looks like an HTTP header <-- 221 2.7.0 Error: I can break rules, too. Goodbye. [connection closed] -- Postfix treats this as GAME OVER $
- 2. TLS 証明書の使いまわしを避けること。
ワイルドカード証明書は非常に広く使用されており、ビジネスネットワーク上の何十、何百もの異なるサブドメインを管理する管理者にとって便利なものです。
とはいえ、できる限りワイルドカードの使用は控え、特定のサービスやサービス群に関連するサーバー名のみを保証するように各証明書を制限してください。
たとえば、すべての Web サーバーや SMTP サーバーが使用できる証明書を取得するのではなく、サーバーの種類ごとに証明書を取得し、それぞれの証明書において関連するサーバーを特定することを検討しましょう。
# This cross-validates all your servers and is easier to manage... $ namedump -subject -san wildcert.pem X509 Serial Number : b876c80b5ae39ee6aa5d9fc4 X509 Certificate Subject : CN = *.example.com X509v3 Subject Alternative Name : DNS = *.example.com, DNS = example.com # These two are more hassle to manage, but identify your resources more precisely... $ namedump -subject -san webcert.pem X509 Serial Number : a4a5525983c90e6c667d6ae0 X509 Certificate Subject : CN = www.example.com X509v3 Subject Alternative Name : DNS = www.example.com, DNS = support.example.com, DNS = downloads.example.com $ namedump -subject -san mailcert.pem X509 Serial Number : e511a5732f4e0cd81ae10cb0 X509 Certificate Subject : CN = mail.example.com X509v3 Subject Alternative Name : DNS = mx1.example.com, DNS = mx2.example.com
- 3. 可能であればApplication Layer Protocol Negotiation (ALPN) を使用すること。
最近の TLS は ALPN と呼ばれる機能をサポートしており、この機能を用いることで、Web ブラウザなどのクライアントと接続先のサーバーが接続時に使用するアプリケーションプロトコル (HTTP/1.1 や HTTP/2、FTP など) を指定できます。
(残念ながら、そして意外なことに、アプリケーションタイプの SMTP はまだ正式には認められていません (2021-06-11T14:00Z 時点) が、カスタムプロトコル文字列により、電子メール接続に smtp を使用することができます。)
ALPN の使用を徹底することは、現在のところ現実的ではありません。なぜなら、サーバーに接続する多くの正規のプログラム (古いブラウザやほとんどの電子メール送信プログラムなど) は、ALPN を使用するように設定されていないか、またはまったく ALPN をサポートしていないからです。
しかしながら、交換するデータの種類を指定しているクライアントの要求に対しては厳密な返信を行うようにサーバーを設定することで、十分な情報を持った訪問者を ALPACA 方式のクロスプロトコル攻撃から守ることができます。
- 4. 可能であれば Server Name Indication (SNI) を使用すること。
1 台の Web サーバーで多くの異なるドメインのリクエストを処理することが特にクラウドではよくありますが、その際、すべてのドメインで TLS 証明書を共有することはできません (し、したくもないでしょう) 。
そのため、TLS では SNI と呼ばれる機能を使って、クライアントが接続先のサーバーで使用する予定のサービスを前もって指定できるようになりました。
サーバーは通常、SNI 情報を使用して、どの TLS 証明書を送信して接続を検証するかを決定します。
さらに、SNI を使用することで、誤ってサーバーに到着した接続や、悪意を持ったリダイレクションによる接続を拒否することもできます。
SNI の使用を徹底し、訪問者が SNI を介して事前に目的を明らかにしない限り接続を拒否することは、今のところ非現実的です。というのも、企業がメールを送信する際、接続要求に SNI データを添付することはほとんどないでしょうし、ブラウザの中にはまだ SNI に対応していないものもあるからです。
しかし、訪問者が SNI を介して前もって意思表示をしたにもかかわらず間違ったサーバーに到達してしまった場合、そのリクエストをブロックすることで、ALPACA のような攻撃からサーバー管理者と訪問者の両方を守ることができます。
適切な対策を行いましょう。