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.5k
バックドアの発見と検証
サーバやネットワーク機器、IoT機器のバックドアの分類と検証方法について。
lumin
July 08, 2022
Tweet
Share
Other Decks in Technology
See All in Technology
AIエージェント元年
shukob
0
160
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
860
Iceberg Meetup Japan #1 : Iceberg and Databricks
databricksjapan
0
350
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
14
4.9k
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
210
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
240
Goで作って学ぶWebSocket
ryuichi1208
3
2.7k
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
630
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
9
2.2k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
340
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
230
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Building Applications with DynamoDB
mza
93
6.2k
Designing for Performance
lara
604
68k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
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しかできないなど実施すべき内容が不充分になる。