世界を動かす技術を、日本語で。

Linux用の無料かつオープンソースのルートキット

概要

  • Singularity はLinux向けの オープンソースrootkit として開発
  • セキュリティ研究用途での利用を強調、悪用は犯罪行為
  • Ftrace を活用し、システムコールやファイル、プロセス、通信を隠蔽
  • x86/x86_64 アーキテクチャ対応、主要ディストリで動作確認
  • 検知・対策研究 のためのテストベッド提供

Singularity: Linux向けオープンソースrootkitの概要

  • Linux用rootkit の多くはクローズドソース、Singularityは オープンソース として公開
  • Matheus Alves 氏が開発、研究目的を明確化
  • MITライセンス でソースコード公開、悪用は著作権侵害ではなく犯罪行為
  • 明示的な許可 があるシステムでのみテストを推奨
  • セキュリティ研究者向けの 新たな検知・回避技術 の検証環境

カーネルフックとFtraceの活用

  • root権限取得やモジュール導入方法 は対象外、既に侵害されたシステムが前提
  • Ftrace を利用し、カーネルのシステムコール処理をフック
  • CPUトラップや関数本体の書き換え を不要化、検知リスク低減
  • Ftrace無効化 を自動的に防止、rootkitの隠蔽性向上
  • 自身・攻撃者プロセス・通信・ファイル の4種を隠蔽対象

自身の存在隠蔽

  • カーネルモジュール一覧やtaintマーカー から自身を削除
  • アンロード不可化、通常のモジュール管理ツールから不可視
  • 後続モジュールのロード も妨害(表面上は成功、実際は失敗)
  • 仮想マシン上での検証 を推奨

プロセス隠蔽の仕組み

  • 32個のPID配列 で隠蔽対象プロセスを管理
  • kill()システムコール をフックし、未使用シグナル(デフォルト59)でプロセス追加
  • グローバル名前空間でroot権限付与、コンテナ外への権限エスカレーション
  • execve()フック による環境変数経由の追加もサポート
  • /procのファイル隠蔽、sysinfo()でプロセス数調整
  • 各種プロセス関連システムコール (getpgid, sched_getaffinity等)もフック

ファイル・ディレクトリ隠蔽

  • getdents()フック によるディレクトリエントリ削除
  • stat()フック で親ディレクトリのリンク数調整
  • openat()等の直接アクセス失敗 を誘発
  • readlink()は個別に対応
  • ユーザー指定パターン のディレクトリ名を隠蔽(デフォルトは"singularity"、設定変更推奨)
  • RAM上の一時ファイルシステム利用 で再起動後の痕跡回避

ログ・証拠隠滅機能

  • /proc/kallsymsやenabled_functions等 のFtrace痕跡をread()フックで隠蔽
  • 既知文字列によるフィルタ、ビルド時のカスタマイズ推奨
  • ファイル完全削除が不自然な場合は内容のみ隠蔽

ネットワーク通信の隠蔽

  • 特定TCPポート(デフォルト8081) の通信を不可視化
  • IPv4/IPv6両対応
  • netstat等からの隠蔽 はファイル隠蔽コードを流用
  • パケットキャプチャ対策 としてカーネルの受信処理フック
  • 外部ネットワークタップからの観測は不可避

アーキテクチャ・互換性

  • x86/x86_64のみ対応
  • 32bit/64bitシステムコール両対応、呼び出し規約変換ラッパー実装
  • Ubuntu, CentOS Stream, Debian, Fedora等6.xカーネル で動作確認
  • Ftrace依存 のため、カーネルアップデートで動作不安定の可能性

痕跡消去用ユーティリティ

  • 証拠隠滅スクリプト を同梱
    • ログローテーション模倣・ログ短縮
    • ローカルビルド時のソースコード完全削除
    • 自動起動設定
  • 主な検知ポイント はFtrace無効化の不可(/proc/sys/kernel/ftrace_enabledが"1"固定)

セキュリティ研究への意義

  • コードはシンプルかつモジュール化、カスタマイズ容易
  • 新たな検知・防御技術開発 のための実例・教材
  • バグ修正・新機能・検知手法の提案 を歓迎
  • rootkitの実力と限界 を体感できる研究用プラットフォーム

Hackerたちの意見

もし誰かがSingularityを悪用したいと思ったら、コードはMITライセンスで自由に入手できるから、そういう使い方をするのは犯罪にはなるけど、著作権侵害にはならないんだよね。著者がMITライセンスを選んじゃったのは残念。もし(A)GPLを選んでたら、犯罪者は改良したソースコードを使う際にLICENSE.TXTのコピーを配布しなきゃいけなかったはず。そうしないと、犯罪であり著作権侵害にもなってた。そういえば、元の著者にクレジットを与えなかったら、MITの下でも著作権侵害になっちゃうね。

たぶん古いジョークだと思うけど、ここで初めて聞いた。笑

まずは弁護士に確認したみたい…笑。彼らの頭の中では、すべての法律は無効なんじゃないかな。

ちょっといいかな、(A)GPLv3を勧めるべきだったね。バージョン3の反ティボライゼーション条項があれば、ユーザーはルートキットを自分の好きな、あるいは悪意のあるバージョンに改造・置き換えできるから、著作権法に違反しない限り。

笑わせてもらってありがとう!

HAHAHAHAHAH 本当にたくさん笑ったよ、ありがとう!

犯罪と著作権侵害の一例。いい区別だね;+1。

使ってると、怒ってるユーザーからのスパムメールが来るのが嫌だよね。sqliteや他の人気オープンソースプロジェクトの作者にもそういうことがあったと思う。技術に詳しくないユーザーは、自分のコンピュータが汚染されてると思っちゃうんだよね。 https://news.ycombinator.com/item?id=42358470

やばい、これがLinuxカーネルモジュールの通常の制限を超える方法の良いガイドだって気づいた。VFSをフックして、プロセスごとにファイルパスを動的に再マッピングできる派生版を作ってるんだ。そうすれば、挙動が悪いアプリにカスタムTLS証明書を読み込ませられるから(nixpkgsのBazilビルド、見てるよ)。もしこれをすでにやってるものを知ってる人がいたら、すごく助かる!

Linuxカーネルモジュールの通常の制限を超える方法。え、どんな制限?モジュールがプローブされた後、カーネルの裏側に回って全く関係ないサブシステムの別のドライバーやデバイスの内部に手を入れるのを止めるものなんて、俺は知らないよ。SoC/SoMベンダーは、BSPでそういうことをするのが大好きだよ。 > VFSをフックしてプロセスごとにファイルパスを動的に再マッピングする。カーネルのVFS内部をいじる代わりに、次のことを試してみたら? - 問題のあるアプリやパッケージをパッチする(理想的にはパスを設定可能にして、それを上流に戻す) - アプリをマウントネームスペースで実行して、パスの上に何かをバインドマウントする - LD_PRELOADを使ってfopen/open/openatをラップする(これに関しては既製のソリューションがすでに存在するはず)

VFSをフックしてプロセスごとにファイルパスを動的に再マッピングする派生版を作ってるんだ。chrootやネームスペース/コンテナはどう?

usernsに+1。あと、proot(ユーザースペースのchroot)やfakechroot(LD_PRELOADを使うやつ)もあるよ。

以前に話題になってたのはここだよね。https://news.ycombinator.com/item?id=46498658

これめっちゃ面白い。ルートキットは実装が難しいし、リバースエンジニアリングなんてさらにレベルが違う。今、ガイダンスがあるね。

Linuxのルートキットについてよく知らないんだけど、これってサイバー攻撃のリスクを高めることになるんじゃない?

いや、すでにたくさんのオープンソースのLinuxルートキットが存在してるよ(ただ、これは他のよりも現代的でメンテナンスされてる感じがするけど)。

Ftraceのメカニズムは実行時に無効にできるから、Singularityは自動的にそれを有効にして、オフにしようとする試みをブロックしてるんだ。Ftraceを強制的にオフにした状態でカーネルをコンパイルすることってできるの? 実行時に無効にできるなら、カーネルが動くためには必須じゃないってことだよね。オフにするだけじゃなくて、Ftraceのコードパスを削除する(デッドコードの排除とか)ことも考えてる。モジュールをロードできない統一カーネルみたいな他の対策にも興味があるけど、今回はそれが質問の趣旨じゃないんだ。Ftraceをカーネルのコンパイル時に完全にオフにできるか知りたいんだ。

そうみたいだね grep FTRACE /boot/config*

知識の自由には賛成だけど、今の世界の情勢を考えると、こういうツールをバカに渡すのは先見の明がないよね… 次はLinux用のマカフィーかな../s

公開されているLinuxのルートキットは、めちゃくちゃ昔から存在してるよね。これに関しては新しいことはない。LinuxのAVもほぼ同じくらいの歴史があるし… この取り組みは、攻撃者よりも新しい防御者やセキュリティ研究者にとってずっと役立つと思う。

こういうルートキットのソースコードはほとんどオンラインにあって、簡単に見つかるから、ルートキット探しが上手くなるんだよね。

ごめん、俺は自分のルートキットはプロプライエタリで、クローズドソースで、クリック同意のEULAがあるやつが好きなんだよね。

ルートキットを買ったりインストールしたりした後にプライバシーポリシーに同意しなきゃいけないのも面倒だよね。

自分のコンピュータがセキュリティ過剰だと感じているユーザーは、リモートコード実行を許可したり、セキュリティ機能を無効にしたり、通常の管理ツールからファイルやプロセスを隠すためにSingularityカーネルモジュールをインストールすることができる。ハハ。