とある親父の侵入実験【Bad-PDFを防いでみる】
結構、反響が良かったのと、ベンダーから公開されている対応策を検証していたらそれなりの量になってきたので、前回の記事への追記ではなくて新しく書き起こしてみた。
そもそものネタは前回のコレ
この時に、ベンダーの対策について処置対策についてご指摘を受け、公開後に追記させてもらったのだが、その際の検証状況については載せていなかった。
１・環境
２・準備
Microsoftが公開した「Windows NTLM SSO認証」対策は「最新のOS」を「最新の状態」にしていることを推奨しているというので、やられPCとして準備していたWindows7は利用できなくなった。そこでWindows10を準備しとりあえずアップデートして最新の状態にした。（マイクロソフトは Windows 10 および Server 2016 でのみこの新しい動作をリリースし、この新しい動作の使用について古いオペレーティング システムを除外しています）
３・検証
前提条件：攻撃側のKali LinuxでBad-PDFを実行し悪意のあるPDFを作成しWindows側へ渡している状態で始める。
Microsoftで公開された対処は、レジストリの以下の場所に「EnterpriseAccountSSO」というDWORD32キーを追加する。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0
まずは、このキーを追加しない状態でPDFを開くと
異常なくダダ漏れになる。
次にレジストリにキーを追加する。
ここに入れる値は公式によると
- 2 - 常に SSO を許可します(これが既定の状態です)。
- 1 - リソースがパブリックの場合は SSO を拒否します。リソースがプライベートまたはエンタープライズの場合は許可します。リソースが指定されていない場合は、SSO を許可します。
- 0 - リソースがパブリックの場合は SSO を拒否します。リソースがプライベートまたはエンタープライズの場合は許可します。リソースが指定されていない場合は、SSO を拒否します。
まずリソースがパブリックな場合や、指定されていない場合は拒否する「０」にすると
これまでと違ってNTLMの情報が流れてこない。
次に値を「２」にすると、SSOを許可する通常の状態なので当然、ダダ漏れ。
Microsoftの推奨する「最新のOS」で「最新の状態」にして、「新しい動作（レジストリへの書き込み）」という処置をした状態ならば対策できることが検証できた。
次にせっかくなのでFoxitについても検証してみた。
ベンダーの発表では9.1のリリースで対応したというのでそれ以前のバージョンと9.1で比較してみた。
まずは8.0.2
攻撃側に一切の反応がない・・・。当然レジストリのキーは削除している。不安になったからAdobe Readerで起動したら異常なく漏れてきた。でも、Foxit 8.0.2 反応なし。
次は、がっつりダウングレードして6.0.5
やはり変化なし。
念のため、ベンダーから保証されている9.1
当然動きはない。
自分の中では9.1以前のバージョンで開くと漏れ出てくれるものだと仮定して検証していたのでかなり肩透かしを食らった気分である。もしかすると、レジストリのキーは削除してあるが、Windowsを最新の状態にしているのが原因なのか？とも疑い始めてもう何が正しいのかわからなくなってしまった。結果としてFoxitに関しては、私の環境ではNTLMの情報を盗み出すことはできなかった。
４・まとめ
Foxitに関して正確な情報を見出せなかったが、とりあえずAdobeは公表通り対応はしていない。しかし、Windows側で対応している。しかし、Windows側の対応は、最新のものだけで古いバージョンに関しては対応しない。
