Sophos Cloud Optix
人工知能 (AI)、ファジィ論理、ニューラルネットワーク、ディープラーニング・・・
人間の「思考」に近い挙動をコンピュータができるようにするこれらのツールは、サイバー犯罪との戦いで大いに役立ちます。
なぜなら、「機械学習」と現在呼ばれているものは、興味深い情報や重要な情報だけを残して関係のない情報を取り除くことができるため、膨大な量の脅威関連データを迅速に処理するのに優れているからです。
だからといって、人間の英知をばかにするのは早計です。
知識豊富な専門家が 1 人いるだけで十分な場合もあります。たとえば、コンピュータセキュリティ専門家の Paul Melson 氏は先週、次のような素晴らしいツイートを投稿しています。
Do you see what I see? —-BEGIN CERTIFICATE—– UEsDBBQ… (皆さんも、おわかりになりますか? —–BEGIN CERTIFICATE—– UEsDBBQ…)
ツイートで言及されているファイルをどこでどのように見つけたのかについて、Melson 氏は明言していません。「不屈のブルーチーマー (blue teamer)」(迷惑ユーザーをネットワークから締め出す、あるいは侵入した迷惑ユーザーを発見して排除することを仕事とする人) を自称していることを考えれば、Melson 氏は今後もその点を明らかにするべきではないし、明らかにするつもりもないと推測されます。ここはひとまず、悪意のあるハッカーによる実験を Melson 氏が潰そうとした際に、このファイルを発見したと仮定します。
セキュリティ研究者であれば、このツイートを見て「すごいな、これは」と言うでしょう。
しかし、システム管理者でなければ、何がそれほどすごいのか不思議に思うかもしれません。そこで、この背景を掘り下げて説明しようと思います。
----BEGIN CERTIFICATE---- UEsDBBQ... というテキストにセキュリティ関係者が身構える理由は何なのでしょうか。
理由は次のとおりです。
警戒すべき理由
HTTPS 接続を許可するように Web サーバーを設定するなど、公開鍵暗号を扱ったことがある方であれば、公開鍵と秘密鍵のペア、そして公開鍵を保証する暗号化された署名付き証明書が必要であることはご存知かと思います。
HTTPS は、TLS (Transport Layer Security) と呼ばれる基本プロトコルに依存しています。大部分の TLS システムは、X.509 というファイル形式を使用して、暗号化されたデータを格納しています。
X.509 は 1980 年代の時流に従って電気通信業界で誕生したファイル形式です。X.509 のネイティブ表現は、DER (Distinguished Encoding Rules) と呼ばれるかなり複雑なバイナリファイルストレージシステムに基づいています。そして、この DER は ASN.1 (Abstract Syntax Notation One) に基づいています。
ではここで、独自の自己署名証明書を作成してみましょう (ここでは LibreSSL にリンクしている Lua コードを使用しています)。
証明書のローバイナリデータを DER ファイルとして保存し、ダンプしたところ、次のように表示されました。
LibreSSL に組み込まれている ASN.1 パーサーを使用してみても、読み取れるテキストにはなりません (下図参照)。
X.509 証明書を破損させることなく電子メールに追加したり、テキストファイルに保存したりできるよう堅牢性を高める目的で、通常 X.509 証明書は次のように PEM (Privacy-Enhanced Mail) 形式で保存されます。
PEM ファイルは、DER のローデータを base64 に変換したものです。base64 はテキストのみの形式で、4 つのテキスト文字を使用してバイナリデータを 3 バイトずつエンコードします。これにより、プレーン ASCII のみが使用され、制御文字やリスクを伴う句読点などを回避することができます。
セキュリティ専門家であれば、今後もセキュリティ関連ファイルで -----BEGIN CERTIFICATE----- を目にすることも多いでしょう。
実際には、しばらくすると証明書を気に留めなくなります。意図的か否かに関係なく、なんらかの変更が加えられると、証明書は自動的に無効になります。
では、Melson 氏が発見した不正な証明書はどこが特徴的だったのでしょうか。
証明書は共有されるために存在します。誰かが Web サイトに接続すると、そのサイトからユーザーに対して公開鍵とデジタル署名が送信されます。デジタル署名は、本当にその Web サイトに対して発行された公開鍵であることを信頼のある第三者機関が保証するものです。
証明書はどのように表示されるのか
信頼された公式の認証局として Mozilla 製品に組み込まれている 150 件の証明書の最初の数バイトをダンプしてみます (これらの認証局は、Firefox ブラウザからアクセスする Web サイトを保証するために Mozilla が現在使用している第三者機関です)。
どの証明書も先頭のバイトが 30 82 0x である点に注目してください。
これは、X.509 のエンコードが必ず次のように始まるためです。
30 - 以下はオブジェクトの X.509 のシーケンスです 82 - 次の 2 バイトは残りのオブジェクトの長さをエンコードします HH - 2 バイト長の上位 8 ビット LL - 2 バイト長の下位 8 ビット
これらすべての Mozilla の「ルート」証明書の長さは、442 バイトから 2007 バイトまでであるため、エンコード後の長さが 0x0100 (10 進数で 256) より小さくなることはなく、0x07FF (2047)より大きくなることもありません。したがって、X.509 エンコーディングは常に次のいずれかのシーケンスで始まります。
30 82 01 00 30 82 01 01 30 82 01 02 . . . 30 82 07 fe 30 82 07 fe 30 82 07 ff
(上図は各 DER ファイルの 16 進数の長さを出力したものです。常に 4 つの数値とシーケンスマークにエンコードされた長さが表示されます。これは、シーケンスマーク自体に使用された 4 バイトとシーケンスの長さを表しています。
次に、30 82 0x で始まる 3 バイトを base64 表記に変換すると、次のようなエンコードされた 4 バイトになります。
Raw Base64 ------ ------ 30 82 00 MIIA 30 82 01 MIIB 30 82 02 MIIC 30 82 03 MIID 30 82 04 MIIE . . .
このパターンは 30 82 3f まで続きます。
Raw Base64 ------ ------ . . . 30 82 3d MII9 30 82 3e MII+ 30 82 3f MII/ 30 82 40 MIJA 30 82 41 MIJB
つまり、長さが 0x3FFF (16,383) バイト未満の X.509 証明書の場合、対応する PEM データの最初の 3 つの base64 文字は、(先ほど作成した PEM 証明書の例のように) 常に MII になります。
したがって、どう考えても ---BEGIN CERTIFICATE---- UEsDBBQ はおかしいのです。
base64 の特性
問題はそれだけではありません。
base64 シーケンスの最初の 2 文字は、元のコンテンツの最初の 12 ビットにデコードされます。そして、一般的なファイルタイプの多くは、常に同じ 2 バイト (またはそれ以上) で始まります。
ファイルの先頭の定数バイトは「マジックナンバー」と呼ばれています。なぜなら、ファイルの種類がそこからわかるからです。
正確に言うと、マジックナンバーを見れば、ファイルがタイプ X であることがわかるか、またはファイルがタイプ Y や Z ではないことがわかります。
一般的な例を以下に示します。
base64 文字列に変換されたシーケンスを以下に示します (わかりやすくするため、2～3 文字に短縮してあります)。
経験豊富なセキュリティ研究者であれば、これらの base64 が与えてくれる数多くの「ヒント」に気付くはずです。また、MZ を表す TV と PK を表す UE しか覚えていなかったとしても、悪意のあるファイルと思しきファイルが一目でわかるはずです。
MZ ファイルマーカーは、EXE および DLL を含めて、形式を同じくするあらゆる種類の Windows 実行ファイルをカバーします。
また、ZIP アーカイブは、拡張子が .APK でありながら ZIP 形式で保存される Android アプリや、ZIP を含むさまざまな内部レイアウトを使用する Microsoft Word ファイルなど、さまざまな目的に使用されます。
これらのことを踏まえると、「何が Melson 氏の目に留まったのか」という疑問が湧いてきます。
最初の UE から、ZIP ファイルであることが即座にわかりますが、では中身は何なのでしょうか。
これは ZIP 形式であるため、解凍して中身を表示すれば、その内部構造から Excel スプレッドシートファイルであることがわかります。
xl/vbaProject.bin というコンポーネントが存在することは、このスプレッドシートにマクロ (埋め込みプログラムコード)が含まれていることを示しています。
vbaproject ファイルから VBA (Visual Basic for Applications) マクロコードを抽出すると、Auto_Open 関数が表示されます。
名前からわかるように、この関数はドキュメントが開かれると自動実行されます。
デフォルト設定の Office では、マクロは自動的に実行されません。したがって、少し注意するだけで安全の確保が可能です (攻撃者がこの方法でマルウェアを拡散させるには、ユーザーに文書を開かせるだけでなく、マクロを有効にするためののボタンをクリックするように仕向ける必要があります)。
C: ドライブのルートディレクトリにインストールされた埋め込み型の Auto_Open マクロは、C:\shell.exe というプログラムの実行を試みるだけであることから、幸いにも Melson 氏が発見した際、サイバー犯罪者はこの攻撃方法をまだ完成させていなかったようです。
通常のユーザーはルートディレクトリに書き込みできないことを考えると、マルウェアを隠すことができる攻撃者は、すでにシステム管理者の権限を持っている可能性があります。したがって、これ自体は大きな影響を及ぼすものではありません。
しかし、身を潜めるにはよい方法です。また、攻撃者は公式の Windows ユーティリティ CERTUTIL.EXE を使用して、ファイルをデコードすることができます。
CERTUTIL は、-----BEGIN CERTIFICATE----- マーカーを認識し、含まれているデータが base64 でデコードされる前に中身を明らかにします。
当然ながら、後で CERTUTIL を使用して抽出された「証明書」を検証すれば、DER 形式とは全く異なるため、すぐに偽物であることがわかります。
しかし、そのことをすでに知っている攻撃者は、CERTUTIL をセキュリティツールとしてではなく、攻撃用のユーティリティとして使用します。
対策
- ファイル名やヘッダーだけを見て、ファイルを信頼しないでください。攻撃者は、できるだけ長い間隠れていられるようにデータを偽装します。
- ダウンロードしたデータの検証は慎重に行ってください。信頼できないファイルの検証に使用するスクリプトやツールが、ダウンロードしたファイルが「何のファイルに見えるか」に基づいてヘルパーアプリケーションを選択しないように目を光らせてください。
2 つ目の対策は分かりきったことですが、見過ごしがちです。
特に、オペレーティングシステムがどう判断するかを確認するためだけにファイルをダブルクリックすることは絶対に避けてください。そのような場合、ファイルが単に表示されるのではなく、予期していなかったアプリケーションでファイルが起動され、さまざまなセキュリティリスクが引き起こされる可能性があります。