IDコラム

【エバンジェリスト・ボイス】Do you know me? – 出かける時は忘れずに！ 2019/07/04 (木)

サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト　フェロー　関原　弘樹    

どんよりとした梅雨空が続きますが今年も折り返し地点の7月に入りました。
7/1に定例の昇格の人事や社員の異動をする企業は多いと思いますが、当社でも7/1に恒例の人事があり昇格者の決定や異動の発表がありました。

当社の仕組みではラインの管理職だけではなく、エバンジェリストもこのタイミングで認定が行われます。
4年前の2015年に7名の認定で開始された当社のエバンジェリスト制度ですが、今年度は4月に継続認定を受けたフェロー3名を筆頭に、前年度からの継続6名プラス新たに認定された5名の計11名のエバンジェリストという体制で当社のプレゼンス向上と技術面のリーダシップに関して貢献したいと思います。

----------------------

さて、先月末にWebでこんな記事を目にしました。

外部サイト：SSH gets protection against side channel attacks / OpenBSD Journal


日本語では以下のような記事になっていますが

外部サイト：OpenSSH、サイドチャネル攻撃に対する防御策を実装 / ZDNET


要は「最近はやりのCPUの脆弱性を利用したサイドチャネル攻撃からSSHの秘密鍵を保護するためにOpenSSHにメモリ上で秘密鍵を暗号化できる機能を追加しますよ！」というお話です。


--念のためキーワードのおさらいです。

★SSHと秘密鍵
⇒ネットワーク接続をされたLinux等のサーバに暗号化されたセッションでログインするのがご存知SSH。

ここでいう秘密鍵はログインするユーザがクライアントシステム内に持つファイルで、サーバ側に保存しているペアとなる公開鍵と合わせて「ログインしているのは公開鍵を登録したこの私で間違いないですよ！」ということの証拠となる。システムに保存中はパスフレーズで暗号化可能。


★サイドチャネル攻撃
⇒サイドチャネル攻撃（side-channel attack）とは、暗号装置の動作状況を様々な物理的手段で観察することにより、装置内部のセンシティブな情報を取得しようとする攻撃（暗号解読）方法の総称である。つまり、正攻法といえる暗号解読とはちょっと違う方法で攻めてみる方法です。

外部サイト：フリー百科事典『ウィキペディア（Wikipedia）』サイドチャネル攻撃

--


SSHで使用するクライアントの秘密鍵はクライアントのIDを証明する重要な機密データであり、漏えい時に対象システムへの不正ログインされるリスクが存在します。

当然秘密鍵はソフトウェア面でも人間の管理面でも漏えいがないよう厳重に取り扱われますが、CPUというシステムを支えるハードウェアに脆弱性 – 例えばキャッシュ経由で権限のない他のプロセスが使用するメモリを読み取れる等 - があるとそれらの努力もむなしく危険にさらされてしまいます。
そのためにソフトウェア側でさらにできることはないか？それが今回のアイディアです。


■これまでの機密データ保護
大切なもの、例えば印鑑です。用心深い人は家では鍵付の金庫に入れて厳重に保管しますね。もちろん必要になればカバンに入れて手でしっかり持っていきます。そんな印鑑が取り出されるのは印鑑を使用するとき。この時ばかりは大事にしまっておくわけにはいきません。

ITの世界でも同様です。暗号鍵を含む機密データ・重要ファイルの保護はこれまで

①保存中の暗号化
②ネットワーク送信中の暗号化

の2つ観点から語られてきました。

①では暗号アルゴリズムや鍵のライフサイクル管理に様々なベストプラクティスがあり、②ではそれに加えて相手の認証や鍵のローテーションという要素も入ってきます。

#ちなみに暗号鍵を暗号化する鍵はKEK（Key Encryption Keyです。そのまま！）とよばれたりします。

そして使用するとき。つまり機密データがメモリに読み込まれCPUによって処理されるときは当然復号されています。

取り出さなければ印鑑は使えないですよね。


■メモリ上のデータの窃取
前項のように保存時に暗号化するような重要なデータも使用するときには平文で展開する必要があるということはある意味必然です。しかし、ここを突いた攻撃が５~6年前に大流行しました。

中心となったのが小売店に設置してあるPOSに感染する「BlackPOS」^※1と呼ばれるマルウェアです。顧客が代金精算のためにクレジットカードを読み込ませるとカード情報がPOSのメモリ上に展開されますが、その瞬間BlackPOSはカード情報を窃取してしまいます。

^※1外部サイト：急増するPOSシステムへの攻撃とPOSマルウェアファミリ / トレンドマイクロ

業界ではこのような被害を防ぐため、現在ではメモリ上にも平文のクレジットカードデータを置いておかないアーキテクチャを策定し、採用^※2していますが、データ窃取の際に無防備にメモリ上に展開されたタイミングを狙うのはかなり効率がいいことがご理解いただけると思います。

^※2外部サイト：P2PEによって新たな局面を迎えるクレジットカード決済

また、SSHでなくSSL/TLSですがOpenSSL実装上の脆弱性をついてサーバのメモリ上に保存されたデータ（SSLのセッションキーを含む！）を窃取する「Heartbleed」という攻撃での騒動を覚えている方もいるかもしれません。

OSやアプリケーションがローカルのメモリ（DRAM）に展開したデータが意図せずネットワーク経由で外部に漏れるなんて想定外と感じる方は多いのではないでしょうか。

外部サイト：OpenSSL 情報漏えいを許してしまう脆弱性 ～Heartbleed 問題～ について


■OpenBSDコミュニティの見解
先の記事で

>この変更によって秘密鍵は、使用されていない際に対称鍵暗号によって暗号化されるようになる。この対称鍵はランダムなデータ（現在は16KB）からなる比較的サイズの大きな「prekey」（原初鍵）から導き出される。

>攻撃者がシールドされた秘密鍵を解読しようとした場合、まずこのprekey全体を高い精度で復元する必要がある。しかし、現行世代の攻撃手法ではビット単位でのエラーがつきものであるため、同手法を累積的に繰り返してもprekey全体の復元はまず不可能なはずだ。

とありますのでKEKである「prekey」が復元される可能性はゼロではないので理論的には完全ではないものの、メモリ上にあるOpenSSHの秘密鍵の安全性については大幅に向上したとコミュニティは考えているようです。


■メモリ上の機密データ
ここからはおまけとしてOpenSSHの利用時に秘密鍵がメモリ上のどのように展開されているか見てみましょう。

#話を簡単にするためにssh-agentというツール経由で行います。

--公開鍵認証とssh-agent--

前提条件となるパスワード認証ではなく公開鍵認証でSSH接続ができるかの確認（例ではクライアントトSSH-TESTからサーバLinux-01へのSSH接続）

 クライアントSSH-TESTに保存されている秘密鍵は暗号化のためのパスフレーズがつけられているため認証時にはパスフレーズ（サーバLinux-01に設定されたユーザパスワードではない）の入力が必要

#ちょっとめんどくさい…

SSH時に毎回パスフレーズを入れるのが面倒という理由で「ssh-agent」というツールにパスフレーズを渡し、都度入力を不要にする

#人間は楽をしたがるもの！！

緑枠の部分でパスフレーズをssh-agentに渡しているので実際にSSHを実行したオレンジ枠の部分ではパスフレーズを入力していない
また、赤枠内のようにssh-agentのプロセスID(PID)が9067であることを覚えておく

ここで秘密鍵はssh-agentに読み込まれている


--プロセスダンプ--

ここでメモリダンプするために「gdb」（いわゆるデバッガ）をインストール


gdbを使用しPID9067のメモリ空間をファイル名dump-01でファイルシステム上にダンプ
これでssh-agentがメモリ上に展開しているデータをすべてdump-01というファイルに格納できた


--ホストSSH-TEST上の秘密鍵--
秘密鍵をcatで確認するとRSA秘密鍵を意味する「-----BEGIN RSA PRIVATE KEY-----」のバナーが確認できる

赤い枠内は「Zx9Q2G～」以下の秘密鍵の値がパスフレーズをベースにしたAES128bitのKEKで暗号化されていることを示している

「Zx9Q2G～」部分はバイナリをASCIIに変換するBase64でエンコードされている

いったんパスフレーズを外して（暗号化を解除）別ファイルにし、平文の鍵の値を確認

同様にBase64で「MIIEowIBAAKCAQEAnXjcM46U5F+8KZ～」となる、これは暗号化されていない秘密鍵の生の値

Base64の値をツールでバイナリにデコードしてバイナリエディタでRSA秘密鍵のバイナリを確認
ヘッダ部分をスキップして16進数の「9D 78 DC 33 8E 94 E4 5F BC 29 9A 7D 0F B4 FB 19～」が確認できる

 

--ssh-agentは秘密鍵を平文でメモリ内に保持しているのか！？--
「9D 78 DC 33 8E 94 E4 5F BC 29 9A 7D 0F B4 FB 19」をキーとして先ほどダンプしたdump-01（ssh-agentが展開しているメモリ空間をファイル化したもの）内をサーチ

あっさりヒット！

それ以降の16進数データ「66 DC 97 80 A6 7E C2 F1 C0 8C 50 2C DB 72 E6 E3 B6 48 2E 30 E0 A0 1F C5 95 71 76 32 A0 15 33 A8～」も一致しているためこのあたりの256byte（2048bit）分のエリアに平文のRSA秘密鍵が保存されていることは間違いないでしょう。

#これを持ってどの程度のリスクと判断するかはシステム構成や他に導入しているセキュリティ対策によるところがありますので更なる分析が必要です。

とりあえず今回は以上です。


■おわりに
ITを理解することと情報セキュリティのベストプラクティスを理解することは悪意のあるものの攻撃に対抗する上で非常に重要なポイントです。

しかし、そのようなスキルをOJTのみで身に着けようとすると非常に長い年月が必要になるでしょう。

自分に合った様々な手法を検討し組み合わせ、必要なスキルを必要なタイミングで手に入れることが重要なのではないでしょうか。


ではまた、次回のエントリーでお会いしましょう。

Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,


コラムの感想やリクエスト、セキュリティに関するお悩みも受付中！
問い合わせよりご連絡下さい。