動機
配布する実行ファイルやDLLには署名する。当たり前の常識1のように考えていましたがなぜ署名の必要があるのか改めて疑問に思いました。
一般的に言われる2コードサイニングのメリットは以下の2つです。
- ファイルの認証元を認証する
- ファイルが改ざんされていないことを保証する
でもこれって最終的にだれが保証しているんでしょう。発行元が怪しかったり、改ざんされていたりするファイルはだれが止めてくれるんでしょうか。本当に安全なのでしょうか。
というあたりがわかっていないので検証した話です。
先に結論
署名してもあんまり意味ない
下準備
署名されるファイル
適当なプログラムを用意します。筆者が一番使うC#で
dotnet new console -o HelloWorld
cd HelloWorld
dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true --no-self-contained
いっぱいファイルができると署名が面倒なので単一実行ファイルです。これでHelloWorld\bin\Release\net6.0\win-x64\publishフォルダーにHelloWorld.exeが出来上がります。中身はdotnet new console
が既定で作るHelloWorldです。
コードサイニング証明書
続いてコードサイニング証明書を作ります。テストなのでオレオレで。OpenSSLをインストールして3パスを通して、
openssl genrsa 2048 > key.pem
openssl req -new -key key.pem -out csr.pem -subj "/C=JP/ST=Tokyo/L=Chiyoda-Ku/OU=miswil/CN=miswil.test"
openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out cert.crt
openssl pkcs12 -export -out miswil.test.pfx -inkey key.pem -in cert.crt -password pass:
これで署名用のmiswil.test.pfxができました。cert.crtは信頼されたルート証明機関にインポートしておきます。
署名付け
dotnetらしくsigntoolを使います4。VisualStudioをインストールしている人はDeveloper Command Promptから、ない人はWindows SDK5をインストールした後パスを通しておきます。タイムスタンプサーバーにはdigicert6をお借りしました。
signtool sign -f miswil.test.pfx -t http://timestamp.digicert.com -fd SHA256 HelloWorld.exe
Let’s 改ざん
出来上がったexeを適当なバイナリエディタで開いて改ざんします。今回はVSCodeのHexEditorプラグイン7を使いました。
実行時にコンソール出力される文字列を"Hallo, World!"にします。悪質ですね。
下準備まとめ
そういうわけで3種類のファイルを準備しました。
- HelloWorld.exe:署名されていないファイル
- HelloWorldSigned.exe:署名されたファイル
- HelloWorldSignedTampered.exe:署名されたあと改ざんされたファイル
まずは署名を確認
右クリック→プロパティから署名を確認します。
- HelloWorld.exe
署名はありません - HelloWorldSigned.exe
署名があります。詳細を選択すると、
署名の詳細が表示されます。 - HelloWorldSignedTampered.exe
おや?改ざんされたのに署名が…?詳細を開くと、
ここで初めて署名が有効でないことがわかりました。
え?プロパティを開いて詳細まで見ないとわからないの?exeを実行するたびにそんなことしないでしょ?
実行してみる
まあ実行されなければいいんです。そうすれば安全ですから。exeをダブルクリックで起動します。
Hello, World!
Hello, World!
Hallo, World!
……普通に実行できてしまいました。未署名exeはともかく、改ざんexeでも警告すら出ません。
Microsoft Defender SmartScreenに期待
コードサイニングの検証について調べると、Webブラウザーからのダウンロードをを経由するときには、ダウンロード時、実行時に検証がかかるそうです8。これはMicrosoft Defender SmartScreen9が仕事をしています。
ダウンロード
というわけで適当なストレージにアップロードしてダウンロードしてみます。
未署名とか、署名のルート証明書を信頼しているかとか、改ざんとか関係なしに全部止められます。これはメッセージにある通り、このファイルのダウンロード実績が少なすぎるからです。アップロードしたばかりですから当然ですね。この警告を表示させないようにするには、EVコードサイニング証明書を使って署名するか、地道にダウンロード実績を重ねて信頼を獲得するかのどちらかのようです。
警告を無視してダウンロードを続けます。するとファイル発行元の詳細が表示されます。
うーん、改ざんされているファイルでも発行元が正しいかのように表示されてしまいます。これではユーザーも気が付かない。
実行
ダウンロードしたexeを実行します。
今度は改ざんされているファイルは不明な発行元になっていますね。でも未署名との区別がつかないです。ダウンロード時には発行元があって実行時には発行元がないという矛盾に気づくユーザーがどれだけいるのか……
いずれのファイルも「実行」を選ぶと普通に実行されました。
結論
ここまで検証して得られた事実をまとめると、
- 署名後に改ざんされたファイルは署名が無効になるがかなりわかりづらい
- 署名や改ざんにに関係なくダウンロード時には警告が出るので、安全なファイルと怪しいファイルのファイルの区別がつきづらい
- 署名や改ざんにに関係なく実行時には警告が出るので、安全なファイルと怪しいファイルのファイルの区別がつきづらい
- 署名や改ざんに関係なく実行できる
署名 | ダウンロード時 | ダウンロード後初回実行時 | 実行 | |
---|---|---|---|---|
未署名 | なし | 警告 | 警告 | 可 |
署名あり | 有効 | 警告 | 警告 | 可 |
署名後改ざん | 無効 | 警告 | 警告 | 可 |
難しい問題だと思います。安全なファイルが区別できたら世の中からマルウェアは絶滅するわけで、そうなっていない以上すべてに警告を出すのも1つの正解だと思います。
とはいえ改ざんは明らかに怪しいのでそれくらいは止めてくれてもいいのではないでしょうか。セキュリティソフトの設定やグループポリシー次第で止まるんでしょうか?今回の検証環境は特別セキュリティを落としているわけではないので、一般的な普通の環境だと思うのですが……
最終的には、手動でファイルのプロパティから署名の正当性を確認するのが一番安全で、結局ユーザーリテラシーに依存するというあまり好ましくない結論となりました。そうであれば署名をする意味ってないような気もしてきます。みんなそれがわかってるから世の中未署名のアプリケーションばかりなのでしょうか?それはそれで怖い。怪しいアプリにパスワードなんか入力しないよう気をつけましょう。
-
少なくとも有償アプリケーションでは…? ↩
-
https://docs.microsoft.com/ja-jp/dotnet/framework/tools/signtool-exe ↩
-
https://developer.microsoft.com/ja-jp/windows/downloads/windows-sdk/ ↩
-
https://knowledge.digicert.com/ja/jp/solution/SO23060.html ↩
-
https://marketplace.visualstudio.com/items?itemName=ms-vscode.hexeditor ↩
-
https://security.macnica.co.jp/blog/2013/12/exeexe-b21e.html
https://mag.osdn.jp/12/11/19/0634216
https://jp.globalsign.com/service/codesign/knowledge/smartscreen.html ↩ -
https://docs.microsoft.com/ja-jp/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview ↩