検出が非常に困難な Linux のマルウェア「Symbiote」 36
ストーリー by headless
困難 部門より
困難 部門より
一度感染すると検出が非常に困難になるという Linux のマルウェア「Symbiote」について、Intezer と BlackBerry Threat Research & Intelligence Team が共同で調査結果を発表している
(Intezer のブログ記事[1]、
[2]、
Ars Technica の記事、
The Register の記事)。
Symbiote はスタンドアロンの実行ファイルではなく共有ライブラリであり、LD_PRELOAD 環境変数を用いてすべてのプロセスの実行時に読み込ませる仕組みだ。すべてのプロセスに感染後は、ルートキットとしてマルウェア関連ファイルをすべて隠ぺい可能になるほか、Barkeley Packet Filter (BPF) をフックしてパケットキャプチャツールから自身のネットワークトラフィックを隠ぺいする。マルウェアとしての機能は認証情報の収集とバックドアで、使用ドメイン名によればブラジルの銀行に成りすましているとみられるが、実際の攻撃に関する明確な証拠は得られていないとのことだ。
Symbiote はスタンドアロンの実行ファイルではなく共有ライブラリであり、LD_PRELOAD 環境変数を用いてすべてのプロセスの実行時に読み込ませる仕組みだ。すべてのプロセスに感染後は、ルートキットとしてマルウェア関連ファイルをすべて隠ぺい可能になるほか、Barkeley Packet Filter (BPF) をフックしてパケットキャプチャツールから自身のネットワークトラフィックを隠ぺいする。マルウェアとしての機能は認証情報の収集とバックドアで、使用ドメイン名によればブラジルの銀行に成りすましているとみられるが、実際の攻撃に関する明確な証拠は得られていないとのことだ。
高性能ルートキット対策は必要 (スコア:3)
Linux であろうと Windows であろうとルートキット検出は、クリーンな環境から検査対象ドライブをマウントしてフルスキャンをかけるのが望ましいでしょう。
仮想化等で使用ストレージ側にスナップショットを取得する機能があり、他の仮想マシンからマウントできる環境なら、本番環境を止めずにできたと思います。検査環境がストレージ上スナップショットを iSCSI でマウントできなくても、仮想環境でローカルディスク扱いにできるでしょう。
# その手のことをやっていたのはもう 6年以上前なので記憶は少し曖昧ですが
物理マシンなら止めて USB メモリからの起動するのが楽です。許容されるなら。Kaspersky Rescue Disk を使っていました。最新版は krd18 [kaspersky.co.jp]かな。ReFS には対応していない気がする。
ルートキットの性能次第だけど通常はファイルアクセスができないぐらいだろうから、dd とかでディスクイメージを検査環境に転送してできるかもしれない。ファイルシステムの機能も使えるかもしれないが zfs send 的な機能を持っているものはあるんだろうか。ググると btrfs send というのはあるみたいだけど。
当然ですが検査環境では検査できるだけで駆除は本番環境を止めないと難しいです。削除すべきファイルがわかっていれば、Linux ならスタティックリンクのコマンドでとか、いっそのことシステムコールしか使っていないプログラムを書いて、削除するくらいはできるかもですが、常識的に考えて侵入されていることがわかったら止めるべきでしょうね。
Re:高性能ルートキット対策は必要 (スコア:1)
それでもBIOSに感染するのとかあるので、完璧では無いという辛み
Re: (スコア:0)
許容されるなら。Kaspersky Rescue Disk を使っていました。最新版はかな。
ロシア的に最新版ではないほうが安全かもしれないですね
Re: (スコア:0)
苦笑するところ。昔はよかったというべき
近頃重いなあとは思っていたが、競合国になってしまったことで、そのへんがいよいよ、軒並みダメになった
なんでこんな仕様があるのか (スコア:1)
LD_PRELOAD 環境変数を用いてすべてのプロセスの実行時に読み込ませる仕組みだ。
ライブラリやらモジュールやらって、各アプリの起動時に、必要なもの読ませれば良いじゃん。
なんでこんなリソースの無駄遣い＋脆弱性の呼び水にしかならんような仕様があるのか理解できん。
Re:なんでこんな仕様があるのか (スコア:1)
今思えばなんでこんな仕様にしたのか、
己の仕事で一度としてそう思ったことのないものだけが石を投げなさい。
Re: (スコア:0)
仕事である限りは誰でも一度はあるだろうなw
気持ちはわかるが厳しすぎ
Re: (スコア:0)
なんだこりゃと思ったら、嫌がらせのために自分で仕込んだ仕様だった。
だれも嫌がらせされてることに気づきやしねえ！
復讐のための完全犯罪とかフィクションでしか成り立たないと勉強になりました。
虚しいからやめた方がいい。
Re: (スコア:0)
自覚のないバカがバンバン石を投げている絵が浮かぶ。。。
Re: (スコア:0)
牧歌的な時代の名残じゃね
WindowsのPATH環境変数みたいなもんでしょ
Re: (スコア:0)
ここに下げよう。PATHじゃない。近いのはAppInit_DLLs だと思う。
ていうか、NTには「そういうの」山ほどある。ガチ勢は大体暗記してるが、兼任管理者なら、このへんいっぺん使ってみとくと役に立つ
https://docs.microsoft.com/ja-jp/sysinternals/downloads/autoruns [microsoft.com]
Re: (スコア:0)
auditとかptraceとか他にもやりようはあるけども
デバッグやテストで関数呼び出しをフックしたい時に、テストコードを埋め込まず手軽に実現できる。
LD_PRELOADで全てのプロセスにライブラリをフック出来てるってことは、
/etc/ld.so.preload辺りを書き換えられてるんだろうし、そこまで出来てるならrootも奪取済みでしょ。
BPFの下りもだけど、脆弱性というよりroot取られてたらどうしようもねーって話題では？と思った。
Re:なんでこんな仕様があるのか (スコア:1)
問題は「知られない」という一点です。
権限取られるのは０デイ脆弱性や内部犯で事実上防げません。
痕跡を消されるのは最悪なんです。対策が遅れるから。
カーネルはROMにして再起動時に署名確認が必要かな。やっぱり
Re: (スコア:0)
カーネル弄られてないから、署名検証でこれは検出できないぞ。
Re: (スコア:0)
別人だが、ロードされるdllに署名が必要ということだと思うぞ。
そもそもこの機能をフォルト無効にした方がいいと思うけどな。
# そうしたらしたでsetenforce 0みたいなことになるんだろうが
Re: (スコア:0)
某日本では有名なウィルス対策企業のLinux製品で、システム標準のlibstdc++.soを読み込むと動かない場合があって、LD_PRELOADを使って同梱されているlibstdc++を読み込ませるというのをやっていました。OSによるライブラリのバージョン違いを吸収させていたんです。
Windowsにもほぼ同じ仕組みがありませんでした？どのOSにもライブラリの差し替えには一定の需要があるんだと思うんですよ。
Re: (スコア:0)
それはLD_PRELOADじゃなくても対策できるし(というかそっちが普通)、
めんどうならスタティックリンクで配れと言いたい。
libstdc++なんてやりがちなものを対策しないそのウィルス対策企業が悪いよ。
Re: (スコア:0)
> libstdc++なんてやりがちなものを対策しないそのウィルス対策企業が悪いよ。
企業からしたら、stdc++ はGCC由来だから ライセンスがGPL。商用ソフトだとスタティックリンクは難しい。
ユーザもそれくらい理解しとけよ、と言いたいところでしょう。
Re: (スコア:0)
libstdc++のライセンスはランタイム例外になってるし、
GPLだとしたらダイナミックリンクでも事情は変わらんよ。
要するに、あなたの言ってることはうそっぱち。
Re: (スコア:0)
結構昔のことなんで、今だったらsnapみたいな仮想環境になっているのかな？期待できないか…
もうその会社とは手を切ったのでわからないですが、凄かったですよ。binディレクトリの下にログファイルを吐いたりとか、おそらくバイナリと同じ場所にログも出す仕様なんでしょうけど、バイナリごとにログファイルの場所がバラバラなんです。これは中身もかなりヤバい代物だろうと思いました。未だに時々悪評が聞こえてくるので、あまり変わってないのかも。
Re: (スコア:0)
標準出力にボコボコ吐き出すやつかな？
Re: (スコア:0)
便利なんよ。
昔、libsegfaultでお世話になった。
Re: なんでこんな仕様があるのか (スコア:0)
> ライブラリやらモジュールやらって、各アプリの起動時に、必要なもの読ませれば良いじゃん。
その必要なものを読み込ませるの使うんだよ。頭使え。同じ名前のライブラリが複数ある時に使うものを選べる。
LD_PRELOAD 無しでどうやってライブラリの開発するんだ？
別環境で実行できないようなライブラリのバイナリ互換性とかチェックするのに必要なんだよ。
いやなら ld-linux 入れ換えて LD_PRELOAD を根本から無効にしても良いし SELinux とかで防御しても良い。
そもそも root 権限取られてる状態で LD_PRELOAD だけ気にしてもしょうがいだろ。
カーネル入れ換えられたり、カーネルモジュール入れ換えられたり、libc 入れ換えられたり、BIOS 入れ換えられたり、どこにでも何でも仕掛けられるんだから。最近なら弱々な systemd とか狙い目だぞ。
危険性はそんなに増えないのに、利便性が増えるから存在してるんだよ。
だからSELinuxを有効にしろといっただぁ (スコア:0)
セキュアじゃねー、検出手段がねぇー、
他依存しなきゃだめ
おらこんなLinuxやだぁ～こんなLinuxやだぁ
Windows使って東京でベコかうだぁ
はっ！
Re: (スコア:0)
apiフックして検出されないようにするなんてごく当たり前の技術だから・・・Windowsでも同じ
Re: (スコア:0)
それは正確ではない。
WindowsではAPIレベルのフック程度ではこの手のウイルスの検知可能です。
Windowsでも困難なのは、システムモジュールを正規にコールして
メモリー上に起動できた段階で、メモリー上に起動している正規の
モジュールを不正プログラムに差し替える行為です。
見た目実行体のハッシュ値が正規と全く同じなので、ハッシュレベルで
マルウェアやウイルス検査しているセキュリティ対策ソフトは全く検知
できない。（最近のエモテットやランサムウェアはこの手の差し替え行
為で内部ネットワーク侵入している）
ぶっちゃけ、端末に入れるレベルのセキュリティ対策ソフトでは、この手の
検知がほぼ検知不可なので、ネットワークスキャナーや次世代ファイアウォ
ールで通信を監視してないと難しい。
Re: (スコア:0)
それでもWindowsはLD_PRELOAD相当がない点でちょっと違う。代わりに、へたするとPATH環境変数やカレントディレクトリまで探すという、別のやばさがある。
全プロセスに仕掛けるのは難しいが、特定アプリを狙うのなら一長一短な具合だと思う。
Re: (スコア:0)
へたするとPATH環境変数やカレントディレクトリまで探すという、別のやばさがある。
つってもおまかんでないなら探す順序は
c:\windows\system32
c:\windows\sysWow64
アプリ等のカレントディレクトリ
PATH環境変数
だから大した問題ではないかな
アプリが呼んでるライブラリと同名の悪意あるファイルをアプリディレクトリに置いてもシステムディレクトリにある同名ライブラリが優先されるのが今のWindowsの標準
アプリ事態が元々悪事働くならそもそもこの話の外だし
アプリのスタティックライブラリが侵されているのもこの話の外だし
システムディレクトリが侵されているなら最早なんでもアリなわけで
Re: (スコア:0)
同意。カレントディレクトリとPATHは優先度がとても低いのでだいたい問題ないことを大変大雑把に「へたしたら」という表現にした。カレントディレクトリよりEXEのあるフォルダが先に検索されるので、アプリ固有のDLLだってEXEと同じフォルダに置けば問題ない。
Re: (スコア:0)
> ベコかうだぁ
DELLのPCを買うってことですね。
Re: (スコア:0)
gateway [gateway.com]じゃなくて？
Re: (スコア:0)
すみません間違えました...
環境変数自体が今となっては危険だと思う (スコア:0)
特定の変数のみ書き込み禁止とかアクセス制限する方法ありませんよね？
Re: (スコア:0)
特定の変数のみ書き込み禁止とかアクセス制限する方法ありませんよね？
Windowsのその辺の設定はレジストリ管理なんでレジストリ監視しとけばいいんじゃない？
Powershellでスクリプト書いてタスクスケジューラで回す感じで