前回までとは雰囲気を変えて防御手法ではなく攻撃手法に着目する回。
題材は「DLLプリロード攻撃」、それも特に静的リンクの物に絞ります。
簡単に説明すると、.exeと同じフォルダに細工した.dllファイルを配置するだけで.exe起動時に実行されてしまうよっていう攻撃のことです。
今回はこの攻撃の原理と防御法について一通り解説していきます。
いつものようにサンプルコード DllPreloadingAttack.zip
実演
百聞は一見に如かずということでまず実演してみましょう。
PrintVersion内のPrintVersion.exeを起動してみてください。
これは単にバージョンリソース内のバージョンを標準出力に出すだけの極々一般的なアプリです。
では次にexploit内のversion.dllをPrintVersion.exeと同じディレクトリに配置してからPrintVersion.exeを実行してみてください。
表示が変わりましたね 。
これがDLLプリロード攻撃です。
何が起きたのか
WindowsOSが提供するAPIは.dll形式でアプリに提供されています。
その機構に乗っかってアプリの一部を.dllに分離することもできます。
しかし、どの.dllを使うかはファイル名1つで決められているため、OS提供の物かどうかは.exe視点だと区別がついていません。
※LoadLibrary関数による動的ロードの場合はその限りではない
なのでOS提供の.dllの”一部”は、同名の.dllを特定ディレクトリに配置することで勘違いさせ無理やりロードさせることが可能なのです。
DLLの検索順序は公式に説明されています。
この順序で検索して、本物の.dllより前に偽物の.dllを配置することが出来ると攻撃が成立するわけですね。
防御その1、書き込み不能ディレクトリに配置する
検索順序は要するに「.exeと同じディレクトリに同名の.dllがあるとそちらを優先して読んでしまう」です。
※カレントディレクトリの.dllを読んでしまうケースもありますが、そちらはOSの脆弱性として対処される流れのようです。
逆に言えば攻撃者がそこに書き込むことが出来ないならば、いくら脆弱でも問題はないわけです。
例えばProgram Filesがユーザー権限では書き込み不能なのはこのためです。
逆に言うと、Program Files以外に.exeを配置する場合(例：インストーラー)には別の対策が求められます。
防御その2、出来るだけ動的ロードを行う
LoadLibraryのロードでフルパスを指定することでDLLプリロード攻撃はおおよそ防ぐことが出来ます。
※後述しますがLoadLibraryが実装された.dll自体はDLLプリロード攻撃される恐れはありません。
そこでLoadLibraryとGetProcAddressを駆使してフルパスによる動的ロードを徹底することでDLLプリロード攻撃からは堅牢にすることが出来ます。
問題は、その作業がかなりの手間であり、実装コストが跳ね上がることでしょうか。
実際の修正例はPrintVersion_sono2として入れてあります。
実行例：
修正部(※一部)：
typedef DWORD (WINAPI *GetFileVersionInfoSizeW_T)(
_In_ LPCWSTR lptstrFilename,
_Out_opt_ LPDWORD lpdwHandle
);
...
int main() {
wchar_t versionPath[MAX_PATH] = { 0 };
::GetSystemDirectoryW(versionPath, _countof(versionPath));
::wcscat_s(versionPath, L"\\version.dll");
const HMODULE module = ::LoadLibraryW(versionPath);
const GetFileVersionInfoSizeW_T GetFileVersionInfoSizeW = reinterpret_cast<GetFileVersionInfoSizeW_T>(::GetProcAddress(module, "GetFileVersionInfoSizeW"));
防御その3、安全なDLLのみを使用する
検索順序で少し説明されていますが、Windowsにおいては絶対にシステムディレクトリから読まれる.dll名というのが存在します。
具体的には
- NT Object Manager領域に公開されているKnownDLLsに含まれる.dll(レジストリの方じゃないので注意)
- API Setに含まれる.dll
- twain_32.dll
の3種類です。
KnownDLLsは以下
| advapi32.dll | bcrypt.dll | bcryptPrimitives.dll | cfgmgr32.dll |
| clbcatq.dll | combase.dll | COMCTL32.dll | COMDLG32.dll |
| coml2.dll | CRYPT32.dll | cryptsp.dll | difxapi.dll |
| gdi32.dll | gdi32full.dll | gdiplus.dll | IMAGEHLP.dll |
| IMM32.dll | kernel.appcore.dll | kernel32.dll | kernelbase.dll |
| MSASN1.dll | MSCTF.dll | msvcp_win.dll | MSVCRT.dll |
| NORMALIZ.dll | NSI.dll | ntdll.dll | ole32.dll |
| OLEAUT32.dll | powrprof.dll | profapi.dll | PSAPI.DLL |
| rpcrt4.dll | sechost.dll | Setupapi.dll | SHCORE.dll |
| SHELL32.dll | SHLWAPI.dll | ucrtbase.dll | user32.dll |
| win32u.dll | windows.storage.dll | WINTRUST.dll | WLDAP32.dll |
| wow64.dll | wow64cpu.dll | wow64win.dll | WS2_32.dll |
※Windows10 Version1809のもの
WinObjを使えばだれでも見れます、
各バージョン別の内容はhttps://windowssucks.wordpress.com/knowndlls/さんとかが追っているようです。
API Setはapi-ms-win-*あるいはext-ms-win-*で始まるdllのこと。
※関連してVirtualDLLの仕組みという記事を過去に書いたこともあります。
twain_32.dllは特例(あるいは過去の遺物)で、プリロードとLoadLibraryAに限って.dllまで省略せずに指定した場合のみシステムディレクトリからロードされる実装になっています。
おそらくは下位互換の都合でしょう。
これは例えばwindows互換OSを目指しているreactOSでも再現されています。
https://doxygen.reactos.org/de/de3/dll_2win32_2kernel32_2client_2loader_8c.html#ab6c0d4229db6159ce0cc96228f87b811
上記までに含まれる.dllのみを静的リンクする分にはDLLプリロード攻撃される心配はないので、その範囲でのみ実装することで堅牢にすることが出来ます。
実際にAPI Setを使用するようOneCore.libでリンクしたPrintVersion_sono3.exeが入れてあります。
※古いWindowsだとリンクエラーで動きません。
※API Set的にはapi-ms-win-core-version-l1-1-0.dllとapi-ms-win-core-version-l1-1-1.dllでリンクされていますが、version.dllをそちらの名前にリネームしても同様に正常動作します
組んだアプリが実際に大丈夫かはMSDNなど公式のドキュメントから得られるdll名と別途突き合わせてください。
防御その4、setup.exeにする
※2019/03/26 18:30頃追記
なんとsetup.exeというファイル名だと常に全.dllがシステムディレクトリから優先してロードされる挙動になる。
なんでもインストーラーがDLLプリロード攻撃される事例が相次いだために例外的対処として入ったとかどうとか……。
本当に最後の手段だが、setup.exeというファイル名を使うという手があることは覚えておいてもよいかもしれない。
防御その5、DEPENDENTLOADFLAGを設定する(Windows10限定)
※2019/03/28 21:00頃追記
VisualStudio C++のリンカオプションに/DEPENDENTLOADFLAG:0x00000800 を指定することでシステムディレクトリ以外の.dllとのリンクを抑止可能。
このオプションはLoadLibraryおよび起動時のリンク処理のデフォルト挙動を変更するオプションで、0x00000800はSystem32からのみ.dllを探索するように変更するもの。
当然ながらアプリケーションディレクトリに.dllを並べるタイプのアプリでは使用できない。
そういう場合は防御その1に書いた通りProgram Filesへ配置してください。
主にインストーラーや.exe単独で動作するアプリ向け。
詳しくはMSDNのDEPENDENTLOADFLAGおよびLoadLibraryExの仕様を参照してください。
ちなみにWindows10 RS1未満だとただ指定無視されて従来と同じ動きになります。
結論
Program Filesに置く以外の対策は非常に面倒かつ難しく、普通のプログラマーではミスなく終えるのはまず無理というのはわかってもらえたかと思います。
のでProgram Filesに置く運用大事。
とはいえMSは公式にアプリケーションディレクトリを介する攻撃について
アプリケーション ディレクトリにおける DLL の植え付けのカテゴリに該当する DLL の植え付けの問題は、多層防御の問題として扱われ、更新プログラムは将来のバージョンについてのみ検討されます。 ～中略～ その攻撃の本質はソーシャル エンジニアリングです。
https://blogs.technet.microsoft.com/jpsecurity/2018/04/10/triaging-a-dll-planting-vulnerability/
と述べており、基本的には脆弱性ではないとする方針のようです。
ちなみに一番問題になるのがインストーラーのケース(ダウンロードフォルダから実行されやすい)、次が特権実行されるアプリのケース(特権昇格に繋がる)です。
これらに該当しない場合、対応しなくても社会通念上許されることがほとんどです。
終わりに
私の作ったものにはこのdllプリロード攻撃を善用しているものが多数含まれています。
そういった関係から溜まった知識をダンプする目的で記述したため、他に比べると有用性は大分低い記事になったかもしれません。
ではまた、次を書く機会があればその時に。
2019/03/26 14:30追記：
脆弱かのチェッカー作ったのでよかったら見て
「DLLプリロード攻撃のチェッカーをリリース」