弁財天

→FinFisherの世界

Windows Process Injection: KernelCallbackTable used by FinFisher / FinSpy https://t.co/9xbVCr4Lak

— Nicolas Krassas (@Dinosn) 2019年5月26日

「Windowsのプロセスへのインジェクション: KernelCallbackTableをFinFisher/FinSpyが使う」

The surveillance spyware FinFisher, also known as FinSpy, uses what Microsoft called an “interesting and quite unusual” method of process injection via the KernelCallBackTable. The method of injection has been used for 10+ years by the game hacking community to cheat and no doubt used for other nefarious purposes longer. My intention with this short post is not to encourage malicious activity using the KernelCallbackTable, but to make the reader aware of how it’s already being misused.

「KernelCallBackTableを経由したプロセス・インジェクション方法は１０年以上前から ゲーム・ハッキング・コミュニティのチートと、それ以外の極悪な目的のために長い間使われてきた。」

あー、WindowsのDirectXで実装するゲーム業界かぁw。

KernelCallbackTableへのポインタが記述されたPEB(Process Environment Block)を取得する 裏口のカギはWM_COPYDATAをSendMessage()するだけw

WM_COPYDATAはWM_PAINTみたいなWindowsのメッセージw

つまりこれ、脆弱性ではなくWindowsの仕様だ。そんな脆弱な基盤を提供していたのはマイクロソフト。そしてそんなビジネスをいまはフェイスブックがやってるw。

→カネを払えばアプリにデータベースの生の個人情報にアクセスさせてやるという回りくどい商売w

FinFisher exposed: A researcher’s tale of defeating traps, tricks, and complex virtual machines https://t.co/AWF9k1qF9z via @msftsecurity pic.twitter.com/ofM8cUtksw

— The Hacker News (@TheHackersNews) 2018年3月2日

Stage 1: Loader malware keeps sandbox and debuggers away

「Figure 7. FinFisher loader calling native Windows API to perform anti-debugging tricks」
「図７．FinFisherローダーがネイティブなWindowsのAPIを呼び出して耐デバックのトリックを実行する」

The loader’s anti-debugger code is based on the following three methods:
The first call aims to destroy the debugger connection:
NOTE: This call completely stops the execution of WinDbg and other debuggers
The second call tries to detect the presence of a debugger:
The final call tries to destroy the possibility of adding software breakpoint:

デバックされているかを判断してデバッカーとの接続を切断してブレイクポイントの設定の破壊を試みるw

Stage 2: A second multi-platform virtual machine

32ビットと64ビットの両方のプラットフォームの仮想マシンw

Stage 3: Installer that takes DLL side-loading to a new level

atmarkit.co.jp→Windowsのユーザーアカウント制御（UAC）を一時的に無効にする (1/2)(2014年11月5日)

「UACは不適切な操作やウイルスなどから、システムの乗っ取りや破壊を防ぐ重要な機能だ。しかし、この機能のせいでシステムの設定作業やアプリケーションのインストールに失敗することも。UACを無効化することは可能だが、セキュリティを維持するため、作業後は速やかにUACを有効化した方がよい。」

管理者権限を取得するのではなくユーザーアカウント制御(UAC)をバイパスする仕掛けw

Stage 4: The memory loader – Fun injection with GDI function hijacking

In the low-integrity case (under UAC) the installer simply injects the stage 5 malware into the bogus explorer.exe process started earlier and terminates

UAC環境下では前に起動した偽の「explorer.exe」にマルウェアを注入して終了w
うっは。これって片山祐輔のC#のiesys.exeじゃなくて本物のexplorer.exeに感染させる仕掛けだわw

→PC遠隔操作事件のメチャクチャ逮捕タイムライン

4. Open winlogon.exe process
5. Load user32.dll system library and read the KernelCallbackTable pointer from its own process environment block (PEB) (Note: The KernelCallbackTable points to an array of graphic functions used by Win32 kernel subsystem module win32k.sys as call-back into user-mode.)

winlogon.exeプロセスにアクセスしてuser32.dllの Win32カーネルサブシステムが使うグラフィクス関数(GDI)のポインター配列である KernelCallbackTable のアドレスを書き換える…w

GDIかぁ…ここでNVIDIAのプロプライエタリ・ドライバの登場かぁ…w

KernelCallbackTableとGDIを使った攻略コードを隠蔽するために、独自の仮想マシンのコードを動的に実行してウィルス対策ソフトから発見不可能にさせているw。こんな実装を片山祐輔だけで開発することはできないw

Stage 5: The final loader takes control

「set up a special Structured Exception Hander routine, which is inserted as Wow64PrepareForException in Ntdll.」
特殊な構造化例外ハンドラーを設定してNtdllのWow64PrepareForExceptionに挿入。エラーをもみ消すw

Stage 6: The payload is a modular spyware framework for further analysis

で、このFinFisherはスパイウェアの実行基盤の上で種々のスパイウェアが動作させる商売…

1億円超で「世界で最も危険なマルウェア6つに感染したノートPC」が競売中https://t.co/z3EbJrnJUh

— GIGAZINE(ギガジン) (@gigazine) 2019年5月26日

IT業界「人手不足」と「大量の人余り」が同時発生　これってどういうこと？（THE PAGE） #thepage_jp https://t.co/uihA40HYjr

— THE PAGE（ザ・ページ） (@thepage_jp) 2019年5月26日

従来のIT技術者の仕事は画面や帳票など表層的な開発と修正だった。それが人工知能の登場で業務をRPA(ロボティック・プロセス・オートメーション)に馴染むように修正することを要求されている。これはフレームワークやインフラ周りの仕事なので決定的なスキルのミスマッチになる。

画面の開発ではなく、業務にSOAや公開可能なAPIを作り、昔EBIなどと言われた統合の人工知能版を迫られている。

もっと現状を正確に表現するなら、異常に使いにくい矛盾のあるアプリを意図的に構築してマネロンや不正処理に使ってきた。しかしいまでは人工知能を同調圧力で騙すことはできない。RPAの登場でマネロンを基軸にした業務はにっちもさっちもいかなくなったのだ。

ここでのジレンマは「誰が人工知能にアプリの裏操作を教えるのか？」であるw。それは会社や組織にとって最高機密なので「RPAに教える」ことなどできないのだw。

「重要なのは運用フェーズ」というたわごと、若手技術者よだまされるな #保守運用 #人月商売 #基幹系システム #アジャイル開発 #ITキャリアアップ https://t.co/CdnrlXBGvH

— 日経 xTECH IT (@nikkeibpITpro) 2019年5月26日

COBOLをUTF8に対応させようとした場合に全面的な書き直しが必要であることに気付いた話を思い出したw。

→20年前に作製されたCOBOLコードを NLS_LANG=Japanese_JAPAN.AL32UTF8 と LANG=ja_JP.UTF-8 で JIS X 0213:2004 に対応させるw