Writeup : 2020年に修正されたとある脆弱性について

どうもみむらです。

年末です。後数時間で年が変わります。
私はといえば、「千葉県少年少女オーケストラとアキラさんの大発見コンサート2020」の放送を見ながら、この記事を書き終えたらソバをと最後の力をふりしぼっているところです。

宮川彬良さんのアルバム、時々仕事中にも聞いておりますが
音楽の中に遊びというか楽しみポイントが多数含まれているのもあって、すごい人だなと思うわけです。

・・・いや、今回はそういうことを書きたいわけではなくて。

今年、9月頃にとある一つの脆脆弱性が修正されました。

私が報告者になっているもので古いバージョンの製品に含まれていたものではありますが、
色々なベンダーさんでもやってしまいそうな知見が多々ありましたので
軽くご紹介できたらな、と。

なお、仕事柄脆弱性診断は行っておりますが、
趣味の範囲での発見で既に修正されているものになります。

またこの記事は特定の製品やブランドを貶めることは一切目的としておりません。
自社の製品に対して「こういう脆弱性あるかも知れない」という気づきとして使って頂くことを目的としておりますので、ご理解ください。

今回の脆弱性では
「ソフトウェアアップデート」の処理において下記のような問題点がありました。

ソフトウェアアップデートのファイルの検証に不備があり
任意のファイルを挿入できた。
ソフトウェアアップデートのファイルの処理に不備があり
高権限で任意のコードを実行できた。

1．ソフトウェアアップデートのファイル検証

今回のソフトウェアではアップデートの方式が下記のような仕組みになっていました：

サーバからアップデートのメタ情報を取得する
メタ情報に手元のソフトウェアより新しいソフトウェアがあればダウンロードする
アップデートに際し追加の処理が必要な場合は実行する

今回一つ目の問題点だったのは
「ソフトウェアアップデートのファイル検証」が不十分だったことでした。

ダウンロードしたファイルに付属しているメタデータは下記のような構造でした。
（実際にはもっと多くの情報などがあり、このように簡易な形にはなっていません）

ここにおいてのファイルチェックの方法に下記の不備がありました。
（繰り返しではありますが既に修正済みです）

“file” 要素で記述されているファイルのみチェックされる
→ 記述されていないファイルはチェックされない
“file” 要素で書かれている内容が MD5 や SHA1によるファイルのハッシュのみだった。
→ ファイルの整合性は検証できるが、
　「信頼出来るところからのものか」を検証できない

今回のケースでは、その先の処理でファイルの信頼性の検証は行われていましたが
ソフトウェアアップデートの処理を作成する際に上記のような項目のテストは
抜けがちになるのではないかと感じています。

対策としては下記のような追加の検証処理の追加や、
テストコードの追加が出来るとよいかと思います。

MD5 や SHA1 などの整合性チェックに加えて
電子署名を用いたアップデートファイルの信頼性の検証を付加する
アップデートファイルが zip や tar といった一般的なアーカイブファイルを併用している場合などは、メタ情報などに記述されていないファイルが入っていた場合に検証を失敗させるなどする。

1に関しては例えば OpenSSL を用いて下記のような処理で実現できます：

# ベンダーが持つ秘密鍵で電子署名を作成する
$ openssl dgst -sha256 -sign private-key.pem patch.zip > patch.sig

# 受け取り側では公開鍵と提供された署名 (patch.sig) を用いて検証する
$ openssl dgst -sha256 -verify public-key.pem -signature patch.sig patch.zip

C# ですと “RSAPKCS1SignatureDeformatter.VerifySignature” などを用いて
実現するのも良いと思います。

参考例 / 引用元 : デジタル署名を作成、検証する – .NET Tips (VB.NET,C#…)
https://dobon.net/vb/dotnet/string/digitalsignature.html
( 一部コードの修正などを筆者側で加えています )

using System;
using System.Text;
using System.Security.Cryptography;

/// <summary>
/// デジタル署名を作成する
/// </summary>
/// <param name="message">署名を付けるメッセージ</param>
/// <param name="privateKey">署名に使用する秘密鍵</param>
/// <returns>作成された署名</returns>
public static string CreateDigitalSignature(
    string message, string privateKey)
{
    //メッセージをバイト型配列にして、SHA1ハッシュ値を計算
    var msgData = Encoding.UTF8.GetBytes(message);
    var hashData = (new SHA1Managed()).ComputeHash(msgData);

    //RSACryptoServiceProviderオブジェクトの作成
    var rsa = new RSACryptoServiceProvider();
    //秘密鍵を使って初期化
    rsa.FromXmlString(privateKey);

    //RSAPKCS1SignatureFormatterオブジェクトを作成
    var rsaFormatter = new RSAPKCS1SignatureFormatter(rsa);
    //署名の作成に使用するハッシュアルゴリズムを指定
    rsaFormatter.SetHashAlgorithm("SHA1");

    //署名を作成し、文字列に変換して返す
    return Convert.ToBase64String(rsaFormatter.CreateSignature(hashData));
}

/// <summary>
/// デジタル署名を検証する
/// </summary>
/// <param name="message">署名の付いたメッセージ</param>
/// <param name="signature">署名</param>
/// <param name="publicKey">送信者の公開鍵</param>
/// <returns>認証に成功した時はTrue。失敗した時はFalse。</returns>
public static bool VerifyDigitalSignature(
    string message, string signature, string publicKey)
{
    var msgData = Encoding.UTF8.GetBytes(message);
    var hashData = (new SHA1Managed()).ComputeHash(msgData);

    //RSACryptoServiceProviderオブジェクトの作成
    var rsa = new RSACryptoServiceProvider();
    //公開鍵を使って初期化
    rsa.FromXmlString(publicKey);

    var rsaDeformatter = new RSAPKCS1SignatureDeformatter(rsa);
    //署名の検証に使用するハッシュアルゴリズムを指定
    rsaDeformatter.SetHashAlgorithm("SHA1");

    //署名を検証し、結果を返す
    return rsaDeformatter.VerifySignature(hashData,
        Convert.FromBase64String(signature));
}

余談ですが、今回脆弱性を発見するきっかけになったのは
「メタ情報」に容易にアクセスできたことでした。

今回、ソフトウェアが Windows の Proxy 設定をアップデート時に使用するようになっており、プロキシを挟んだ途端に上記のように通信が確認出来る状態になりました。

Windows では Proxy 設定は、グループポリシ等で制約している場合を除き、

KEY : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Element: ProxyServer 
Type : REG_SZ

またこのとき、アップデートの通信に関し HTTPS 通信で行われていましたが、
HTTPS 通信の証明書の検証は行われておらず、改竄した内容がそのまま信頼される状態になっていました。

HTTPS 通信の証明書の検証は、一般的に検証をした方が不必要なリスクから守ることができる場合が多いため行った方が良いです。

ただ今回のような「アップデータ」の場合は、検証に失敗したことによってアップデートが出来なくなるという可能性も考えられますので、どちらのリスクを取るかは検討した方が良いかと思いますし、先述のファイルに対する電子署名を信頼して、HTTPS 通信の証明書の検証はしないという選択もありだと思います。

また、今回の脆弱性を外部から悪用する場合、DNS の変更か Proxy の変更が必要でした。
（その他の方法もありますが割愛します）

世の中を見渡してみますと「インターネットの高速化」などを偽って、ローカルの DNS 設定を書き換えてしまうマルウェア ( 例：ユーザーに気付かれずにひそかにDNS設定を変えてしまう「DNSアンロッカー」 / マルウェア情報局 ) や脆弱なルータを突いて設定を書き換えてしまう攻撃 (例：ルーターをハッキングし、利用者をフィッシングサイトへリダイレクトする攻撃 / カスペルスキー公式ブログ ) も出ている背景がありますので、
必ずしもかなり難しい攻撃ではないと考えられます。

ですので、DNS や HTTPS の証明書といった経路に対して信頼を付与するのではなく、通信内容（今回の場合はアップデートのファイル）について「エンド-エンド」での信頼を前提として、その上で HTTPS の証明書検証をするといったような形がよいと考えます。

2．ソフトウェアアップデート処理が高権限で走っている

アップデートの処理がコンピュータ内で一番高い権限を持っているプロセスで実行されており、アップデート処理を細工することで任意のプログラムを一番高い権限で実行できるようになっていました。

アップデートファイルの展開処理などが高い権限で実行されている場合
アーカイブファイルの細工 (例 : Zip Slip / ディレクトリトラバーサルが発生する zip ファイルを用いて、意図しないファイルの書き換えを行えてしまう ) をはじめとした色々な要因によってファイルの意図しない変更が発生する可能性があります。

対策としては、ファイルの検証は低い権限で行うなど、不必要に高い権限を与えないように設計するのが良いかと思います。

また、今回の例ではありませんでしたが
アップデートの処理が書かれたプログラム（アップデータ）を配布ファイルに含めている実装もいくつか見られます。

この場合、可能であれば既に稼働中のプログラムに処理を入れ（ファイルの書き換えを稼働中の信頼出来るプログラムによって行うようにし）権限を徐々に与えるという形が良いでしょう。

そばが食べたい一心で書いていましたので、
途中誤字や設計としてそれはオカシイ！という点もあるかも知れません。
指摘等は受け付けておりますので、気兼ねなくメッセージをいただければ幸いです。

余談ではありますが、「脆弱性情報」と聞くとその製品を叩いたり「こんな危険なものは使えない！」と思われる方がいらっしゃると思うのですが、それは違うと思っています。

逆に「実はあるのに、みんな黙っている世界」というのを考えてみたら、そっちの方が怖いかと思いますし、それでしたら「どういうことがあって狙われる、こういう風にすることで修正できる」という話を優しく広げていくことが大事なのではないかなと。

私自身、元々ソフトウェアディベロッパーから、今は情報セキュリティ関係を主軸にしていますが、正直「情報セキュリティの人たちすごく怖いな・・」というのはかつてありまして、今も時々感じることはあります。

「これが分かってて当然」「これが出来ないのはオカシイ」という話がよく出てくる世の中ではありますが、失敗しても治していくことができればそれでいいんじゃないかな、とかつての経験とかを振り返りながら思う今日この頃です。
（何かありましたら気兼ねなく聞いてもらえればと！）

それでは、よいお年をお迎えください！

みむらの手記手帳

ときどき Developer ときどき Researcher そんな社会人のいちにち。

Writeup : 2020年に修正されたとある脆弱性について

1．ソフトウェアアップデートのファイル検証

2．ソフトウェアアップデート処理が高権限で走っている

コメントを残す

1．ソフトウェアアップデートのファイル検証

2．ソフトウェアアップデート処理が高権限で走っている

関連記事:

コメントを残す