サイバー・セキュリティ・ソリューション（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,
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
