Docker-不完全紹介

https://docs.google.com/presentation/d/1PQE4tp5xkCHrGppEpiYJBzV1_hgwIJwqw_x-t_dv0z0

WindowsストアアプリへのDLL Inject

これは新しい技術ではありません。

Windowsストアアプリ(Windows Store Apps)は、サンドボックスからされるアプリです。Windows 10インストール後現れた「天気」、「カレンダー」などアプリはその例です。Windows Storeからインストールしたアプリもそのれです。

サンドボックス化されたので、普通のプロセスのように、簡単にOpenProcess(FullAccess...) + CreateRemoteThreadやMapViewOfSectionなどクロスプロセス操作はできません。普通のSetWindowsHookExやSetWinEventHook経由のDLLアタッチもできません。

原因は、UIAccessの制限です。WindowsストアアプリにDLLをアタッチするには、UIAccess=trueのプロセスからしかできない。

SetWindowsHookExの中に、[Windows Store Apps]に対して、特別な制限の記述があります。

ただし、記述が不十分です。実際は、これはWindows 7(or Vista?)からの技術です。

例として、SetWindowsHookExでWindowsストアアプリにDLLをアタッチする要点をまとめます：

SetWindowsHookExを呼び出すEXEは以下の設定が必要です：

1. EXEを作成する時に、VCの設定には、"UAC Bypass UI Protection"にYes。 

２。EXE自体は信頼されるフォルダに置く必要。例えば"C:¥Programe Files¥TestHook"。

３。署名　　（自己署名を利用する場合は、自己署名の証明書をルート信頼機関として登録必要）
詳しい方法は、ここに記述されています。少し古かったので、証明書登録する方法を変更しました。

cd %userprofile%\Downloads
@rem ルート証明書作成：
makecert -n "CN=testroot,O=aaa,C=JP,E=foo@hoge.jp" -sv testroot.pvk -r testroot.cer 
@rem 証明書を作成
makecert -n "CN=test,O=aaa,C=JP,E=foo@hoge.jp" -sv test.pvk -ic testroot.cer -iv testroot.pvk test.cer  
@rem testroot.cerをルート証明機関として導入
certmgr.exe -add testroot.cer -s -r localMachine root   
rem test.pfxを作成：
pvk2pfx -pvk test.pvk -spc test.cer -pfx test.pfx   
@rem 最後に、関連ファイルを署名： 
cd "C:¥Program Files¥TestHook"
Signtool sign /f %userprofile%\Downloads\test.pfx /v .¥TestHook.exe
Signtool sign /f %userprofile%\Downloads\test.pfx /v .¥TestHook.dll

その他注意点：64bitのWindowsの中に、Windowsストアアプリは32bitである場合があります。事前に確認してから、32bitと64bitのDLLやEXEを作成必要です。

署名しないと、どうなるの？TestHook.exeを起動すると、main関数を入る前に、「invalid inferrer ....」みたいなエラーが出ます。

テスト用ソース：

• TestHook.EXE（機能：パラメータで指定されたdllのapiを呼び出す)

int main(int argc, char** argv)
{
    argv++; argc--;
    printf("DLL: %s\n", argv[0]);
    printf("Function: %s\n", argv[1]);
    HMODULE hDll = LoadLibraryA(argv[0]);
    PROC proc = GetProcAddress(hDll, argv[1]);
    proc();
    return 0;
}

• TestHook.dll（機能：hookを設定。ロードされた時、当時のプロセス名が「天気」アプリの特徴と一致すれば強制終了する）

static HMODULE _hModule;
static wchar_t currentExePath[1024] = { 0 };

typedef struct _HOOK_INFO {
    int type;
    const wchar_t * name;
    HHOOK hHook;
} HOOK_INFO;

static HOOK_INFO hooks[] = {
    {WH_CALLWNDPROC, L"WH_CALLWNDPROC", 0},
    {WH_CBT, L"WH_CBT", 0},
    {WH_DEBUG, L"WH_DEBUG", 0},
    {WH_GETMESSAGE, L"WH_GETMESSAGE", 0},
    {WH_KEYBOARD, L"WH_KEYBOARD", 0},
    {WH_MOUSE, L"WH_MOUSE", 0},
    {WH_MSGFILTER, L"WH_MSGFILTER", 0}
};

LRESULT CALLBACK CommonCallback(int nCode, WPARAM wParam, LPARAM lParam) {
    return CallNextHookEx(0, nCode, wParam, lParam);
}

extern "C"
void __stdcall hook() {
    MessageBox(NULL, L"Click me to hook", L"test", MB_OK);
    for (int i = 0; i < _countof(hooks); i++) {
        hooks[i].hHook = SetWindowsHookEx(hooks[i].type, CommonCallback, _hModule, 0);
        if (!hooks[i].hHook) {
            DWORD err = GetLastError();
            wchar_t msg[2048] = { 0 };
            wsprintf(msg, L"Failed to set %s hook. Error %: ", hooks[i].name, err);
            FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM, NULL, err,
                MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), msg + wcslen(msg), _countof(msg), NULL);
            OutputDebugString(msg);
        }
    }
    MessageBox(NULL, L"Click me to unhook", L"test", MB_OK);
    for (int i = 0; i < _countof(hooks); i++) {
        if (hooks[i].hHook)
            UnhookWindowsHookEx(hooks[i].hHook);
        hooks[i].hHook = 0;
    }
}


BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        _hModule = hModule;
        DisableThreadLibraryCalls(hModule);
        GetModuleFileName(NULL, currentExePath, _countof(currentExePath));

        {
            wchar_t msg[4096] = { 0 };
            wsprintf(msg, L"I am in process %s cmdline: %s", currentExePath, GetCommandLine());
            OutputDebugString(msg);
        }

        if (wcsstr(currentExePath, L"Microsoft.BingWeather_4.17.74.0_x86__8wekyb3d8bbwe")) {
            TerminateProcess(GetCurrentProcess(), 1);
        }

        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

実行方法は、

cd "C:¥Program Files¥TestHook"
TestHook.exe .¥TestHook.dll hook

[click me to hook]のOKを押して。TestHook.dllを全てのGUIアプリにアタッチ(厳密に言うと、すぐにアタッチするではなく、何らかのWindows関連のMessageが来るとロードされる。)

この状態で、「天気」アプリを起動すると、一瞬画面が現れてすぐに終了されます。

Windowsグループポリシーの嘘:Powershellで操作できるって

大分前から、グループポリシーの設定を自動化する需要がありました。やっと、Windows 2012 R2の時代、PowershellからAD上のGPO(グループポリシーオブジェクト)を操作できると歌われました。ただし、実際は落とし穴があります。

• 落し穴１：Powershell中のグループポリシーモジュールは、ADと組んでいますので、ローカルのグループポリシーを設定するには利用できません。（興味あればMicrosoft.GroupPolicy.Management関連のdllをdotPeekでソースを参照すれば分かります）.

ちなみに、ローカルグループポリシー中のレジストリ設定を変更するには、MSも高層APIを提供していないので、これを利用すればOK。

• 落し穴２：Powershell中のグループポリシーモジュールは、AD上のグループポリシーの中身を自由に変更できません（レジストリベースの設定しか設定できません）。

特に、アプリ配信のポリシーの中身は外部XMLに保存されているし、その中にはさらにバイナリ設定データが入っていますので、Powershellのグループポリシーモジュールは、これらの設定には全然無力です、これらの設定を変更するには、グループポリシーエディターが利用している該当グループポリシー拡張COM DLL(typelibなし)を無理やり利用するしか方法ない。

他に、ファイル設定、タスク設定、サービス設定、AppLocker、SRPなどはバイナリなしのXMLに保存されている、同様に、Powershellのグループポリシーモジュールは設定できないが、PowershellでXMLファイルを直接いじることができますので、なんとなく対応できますね。

とりあえず、上記2点。

Windows 10から、MSはMDM(モバイルデバイス管理)機能を内蔵実装しました、機能的には、グループポリシーの機能と重ねているところが多いです。どうやら、単純にMDMの目的であれば、グループポリシーをやめて内蔵MDMに移行する傾向が見えています。

今更、トンネル、ポートフォーワードツールをNode.jsで作成

大昔からポートフォーワード、リバース関連のツールはたくさんありました：
ssh, nc, socat, redir...。(tcp tunnel port forwardでgoogle画像を見れば分かる)。

ただし、Windows上は、上記のようなツールを利用しようとすると、幾つか現実問題に遭遇します：

• インストーラや実行ファイルは、署名されていないので、信頼できません。
• 企業のセキュリティポリシーに利用が制限されます。
• 自分でソースからコンパイルするのは面倒。
• 極簡単なニーズなのに、sshのような複雑なツールに苦労しなければなりません。
• socatなどは接続情報不明瞭。
• socatなどのポートフォーワードは効率良くない(forkを利用するので）。

一方、Windows上は、IPHelperサービスにより提供しているportproxy機能はあります（netsh portproxyコマンドでポートフォーワードを設定できます）。ただし、パフォーマンスが良くないし、変なエラーが出てます（接続は切られたり）。これはおそらく、HalfOpen関連の処理に不十分です。

Node.jsの世界にもこのへんのツールは少しありますが、期待通りのシンプルではありません。

いいや、納得できません。やはり、作りましょう。

• tunnel.js これはsshトンネルの超簡潔版です：TCPポートのフォーワードやリバース over TCPトンネル。設定なし、パスワードなし！ adb forwardやreverseの感じです。

　利用例：tunnel-listen.js 8888でTCPトンネルサーバを起動し、tunnel-connect.js トンネルサーバ:8888 forward 8080 宛先:80で現在マシンの8080をトンネルサーバ経由宛先:80へフォーワードする。逆に、tunnel-connect.js トンネルサーバ:8888 reverse 8080 宛先:80はトンネルサーバ上の8080を現在マシン経由www.yahoo.co.jp:80へフォーワードする。

• forward.js これは単純なポートフォーワドです。パフォーマンスはいい。それに、ENTERキーで中継情報(接続や、データ）は見れます。もう一つ特長は、フォーワード先のソケットサーバはAllowHalfOpenである場合でも対応しています。

ちなみに、ncの超簡潔版nc.jsも作りました。既存のncのサーバモードのコマンドラインの不統一、入力を複数クライアントに送信できないなど、接続情報不明など問題を解消しました。