Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
バックドアの発見と検証
Search
lumin
July 08, 2022
Technology
9
5.4k
バックドアの発見と検証
サーバやネットワーク機器、IoT機器のバックドアの分類と検証方法について。
lumin
July 08, 2022
Tweet
Share
Other Decks in Technology
See All in Technology
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
840
Autify Company Deck
autifyhq
1
39k
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
3
270
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
120
いまならこう作りたい AWSコンテナ[本格]入門ハンズオン 〜2024年版 ハンズオンの構想〜
horsewin
9
2.1k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
AWS re:Inventを徹底的に楽しむためのTips / Tips for thoroughly enjoying AWS re:Invent
yuj1osm
1
570
来年もre:Invent2024 に行きたいあなたへ - “集中”と“つながり”で楽しむ -
ny7760
0
470
バクラクにおける可観測性向上の取り組み
yuu26
3
420
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
170
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
210
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
240
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Art, The Web, and Tiny UX
lynnandtonic
296
20k
A Philosophy of Restraint
colly
203
16k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Faster Mobile Websites
deanohume
304
30k
Done Done
chrislema
181
16k
Rails Girls Zürich Keynote
gr2m
93
13k
Designing Experiences People Love
moore
138
23k
[RailsConf 2023] Rails as a piece of cake
palkan
51
4.9k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Transcript
バックドアの種類と検証方法 杉浦 隆幸 @lumin
バックドアを仕掛ける意味 • 侵入を継続する 侵入してから仕掛けるもの、bind shell, reverse shell, web shell, root
kit • メンテナンスやサポート、実装を容易にする • ディフォルトパスワード、メーカーアカウント、サポートアカウント, IPMI • 予め製品に仕込む • 個体識別アップデート、トレースビーコン、アクセス解析、故意の脆 弱性 • ソフトウェアサプライチェーン攻撃 • コンパイラ、Makefile、プルリクエスト
検査のポイント • 対象の機器、ソフトウェアを深く知っておく必要がある。 • PCの場合、バックドアの仕掛けられる場所はすべてのプロセッ サーに加えて、OSのバックドアの仕掛けられる場所がある部分 になる。(BIOS、ファイル、自動起動、ブラウザプラグイン、 ドライバ、偽装サービス、証明書、脆弱性のあるアプリケー ション、定期的に識別情報を送信するアプリケーション、実行 ファイルの検証が不充分な自動アップデートソフト)
• 存在するだけで、バックドアになるもの • リバース、リバースエンジニアリングを必要とするもの
作為と不作為 • バックドアがあった場合、そのバックドアがどのようない意図 で設置されたのかは、バックドアの種類によって分類できる。 しかしながら、バックドアの存在だけでは判定できないものも ある。 • 作為のバックドア • 侵入後に作成するバックドア(bind
shell, root kit)、RAT • 不作為のバックドア • IPMI • 不作為の作為バックドア • 修正しない脆弱性
作為判定できないバックドア • 意図的な脆弱性、個体識別可能なアップデート機能、トレース ビーコン、メーカーアカウント • メンテナンス、ディフォルト、ハードコードパスワード
検査を逃れる方法と、逃れられない方法 • OSに依存する検査方法は、OSや検査するツールの書き換えで 発見できなくできる。(root kit) • * ファイルシステムから隠す、偽装する • *
プロセスを隠す、偽装する • * 空きポートを隠す • * 再起動時すると消える • * メモリのみに存在する • パケット解析とフォレンジック解析、ファームウェア解析から は、どのような状態であれ、バックドアが動作したときには、 発見できる。
バックドア検証のフロー • 対象を事前調査以内と必要な工数や見積れない。 • 必要なスキルを持つエンジニアをそれから確保する必要がある。 • x86 リバース • ARMリバース
• 暗号解読 • ソースコード診断(各言語ごと) • フォレンジック • ペネトレーションテスト • バックドアがないことの証明は、バックドアがあることの証明より証明が必要な 範囲が広い。
バックドアの仕掛けられるところ と検証方法
ログインプログラム 197x年に仕掛けられ 、1984に発表され普 及した。 この攻撃はコンパイ ラに仕掛けられたた め、ソースコードの みではわからないの で、バイナリコード での検査必要。UNIX
系OSのバックドアプ ログラムではよく実 装された。Linux kernel kitなどにも使 用される。 ソースコードのみで は半手できないもの で、コンパイラに仕 掛けられたので、バ イナリでの検査が必 要とされた。
故意に修正しない脆弱性 ライブラリ系の脆弱性で、なぜかパ ッチを当てていないものなどがある 。なぜ直さないのかは判定できない が、その脆弱性を使って任意のコマ ンドが実行可能になるケース。 オープンソースの部分 であれば、入っている ライブラリなどのバー ジョンを検査する。
bind shell 任意のコマンドが実行できるマシン上でポートを開けてそのポートに接続するとshellアクセスできるようにするもの。任意のコマンドが実行で きた時のさらなるアクセスに利用されることが多い。 プロセスとして残っているので全プロセスを検証かメモリフォレンジックをします。プロセス名などは変更する偽装がされていることもありま す。
• ルータやファイアウォールがある場 合に任意のポートやtcp/443,80,53 な どで待ち受けて、任意のコマンドを 実行できるマシン上でshellアクセス を可能にします。プライベートアド レスしか持っていなくてもアクセス 可能です。各言語ごとに開発されて います。これらのコードはウイルス
対策ソフトで止まるケースも多々あ ります。 • プロセスとして残っているので全プ ロセスを検証かメモリフォレンジッ クをします。プロセス名などは変更 する偽装がされていることもありま す。 reverse shell
Web shell Webサイトや、Web系システムに仕込んで利用する 。 PHP, Java, Ruby on Rails, Djangoなど様々なプラッ
トホーム用にある。単純なコマンドインジェクション 、SQLインジェクションが可能になるようにコードを 仕込むこともある。 既存のWebShellはウィルス対策ソフトで発見できる ことが多い、組込み型は、発見が難しくすべてのコー ドを解析する必要がある。
個体識別可能なサーバープッシュアップ デートプログラム 機器の個体番号やシリアル番号等をサーバーに送 信して、利用者を特定できる状態で、サーバー側 でファームウェアのアップデートの配信と自動更 新を行える仕組みを持つファームウェア、ソフト ウェア。 上記のLTEモジュールは、IMEIをHUAWEIのアッ プデートサーバに送信して、定期的にアップデー ト確認をしている。アップデートするファームウ
ェアはHUAWEI側の判断で任意のファームウェア に入れ替えが可能である。中身は組込みAndroid Linuxである。できる機能は、アプリケーション 間で正しく暗号化されていないものは制御できる 可能である。 自動アップデートプログラムを 検査する。
ディフォルトパスワード ディフォルトパスワードは一番多く利用されるバ ックドアである。IoT機器では一番多い脆弱性で 最も最も危険なものである。個別のパスワードは 実装が固定パスワードより様々な工数がかかるた め、よく使われている。マニュアルに書いてある ことが多いため、マニュアルを入手できれば書い てある。検査方法はマニュアルを検査するだけで よい。admin :
password や root: 12345678 admin : admin 、 パスワードなしなどわかりやす いものも多い。
メーカーアカウント ユーザには公開していないメーカーエンジニア用のメンテ ナンスのアカウント。 ibm, nec, fujitsu など企業名や製品名そのままのことが多い 。 などわかりやすいものが多い。主として機器のメンテナンス 用に利用されるが、ファームウェアの解析により第三者に悪
用されることも多い。 ファームウェアのリバースエンジニアリングによって検証で きる。
ハードウェアディバッグポート ハードウェアに残っているシ リアルポート。JTAGポート。 ハードウェアのデバッグ用に 意図的に残っていることが多 い。 CPUのデータシートからシリ アルとJTAGのピンを特定しパ ターンからポートがあるかど うかをかくにんし、通電状態
などから動作するかどうかを 検証する。JTAGはパスワード がかかっていることもあり容 易に使えないケースも多い。
android debug 組み込み用Androidでよくあるケース。Tcp/5555 等をスキャンして、adbで接続。
• MDMや同等の機能を持ったアプリケーションがあらかじめ 入っている。 ベンダーによるデバイス管理
RAT
バックドア付き暗号(マスターキー機能)
予測可能な乱数シード 予測可能な乱数を使ったアプリケーションもしくは一時的に予測可能になる乱数を使った場 合や、乱数シードを外部送信するなどして、乱数で発生させる秘密鍵や共通鍵を計算可能に します。暗号化や仮想通貨の秘密鍵で利用される場合は仮想通貨を盗むことができる。検査 方法はソースコードやバイナリコ―コードの検査でsrand()関数などを調査する。
改ざん検知機能、 電子署名による正当性検証のない ファームウェア更新機能
Makefile backdoor ソースコードから実行ファイルを作成するときに使用す る、Makefileに仕込まれる、バックドアでコンパイル環 境に侵入できるようになるものを仕込むことができる。 Makefile内でコマンドを実行できるためにそこに入れる だけで任意のコマンドを実行できる。検査方法は Makefileを読んで検査する。
IPMI PMIを使用すると、オペ レーティングシステムや ログインシェルを使用せ ずに、ハードウェアへの ネットワーク接続経由で 、電源がオフまたは応答 のないコンピュータを管 理することができる。OS の再インストールなども
可能。
• UEFIはLinuxが動作してお り、OSレベルのバックドア を仕掛けることが可能と なっている。BIOSレベルで 動作するため、OSレベルで フックすることができる。 BIOS backdoor
BIOS master password BIOSパスワードにおける、BIOS master password。ノートPCのBIOSパスワードを解除する方法として、実装 されている。実質的にBIOSパスワードの保護を無効化する。あらかじめ組み込まれたバックドア。
認証されていない発行機関の電子証明書 CAルート電子証明書をインストールさせるサービスは、その証明書を使って、中間者攻撃を可能にすることがある。
• 秘密鍵の取り扱いが適当なセキュリティサービスでよくある ケース。実装の都合で秘密鍵をサーバーに送信してしまう。 秘密鍵を要求するサービス
バックドアの検証サービス • バックドアがないことを証明することを目的とする。バックドアが あった場合はその時点で終わることもある。 • IoTはファームウェアを入手もしくは取り出すことが第一ハードル (別途提供できる場合はした方が良い) • バイナリ解析はバックドアが仕掛けられる部分を中心に •
かかる期間は解析すべきデータのサイズによる。2~12週ぐらい が一般的 • できる人は少ない。間違ったところに発注すると、脆弱性検査しか しない、Webしかできないなど実施すべき内容が不充分になる。