Hack The Box「Mirai」に学ぶ――「よくある設定ミス」が侵入口になるまで

今回取り上げるのは、Hack The Box に公開されている「Mirai」というマシンです。
CTFや演習用の環境なので、名前だけを見ると「攻略記事かな」と思われるかもしれません。ただ、実際に中を見ていくと、使われている技術や構成自体はとてもシンプルで、正直なところ、特別なことはほとんど起きていません。

それでも、この Mirai は実務の視点で見ると、かなり示唆に富んだ構成だと感じました。
ゼロデイや巧妙な回避技術が出てくるわけではなく、「そこは確認されないまま残りやすいよね」というポイントが、淡々と積み重なっていきます。

環境としては、Raspberry Pi 上で Pi-hole が動いています。
Pi-hole 自体は、DNS レベルで広告やトラッカーをブロックできる便利なツールで、個人利用や小規模な検証環境ではよく見かけます。私自身も、検証用ネットワークで触ることがあります。

ただ、本来 Pi-hole は内部ネットワークで使うことを前提にしたサービスです。
この Mirai では、その Pi-hole が外部からそのままアクセスできる状態になっていました。

「便利だから」「とりあえず動かしたから」「検証用だし後で直せばいい」
こうした理由で導入された構成が、気づけば公開されたまま残っている。
現場で診断をしていると、こうした状態に出会うことは決して珍しくありません。

今回の事例が面白いのは、どこかで大きなミスをしているわけではないのに、全体として見ると“入り口”がきれいに用意されてしまっている点です。
一つひとつは小さな判断でも、積み重なると、外から見た景色は大きく変わってしまいます。

この Mirai は、そうした「現場で起きがちな判断の連なり」を、かなり分かりやすい形で見せてくれるケースだと思います。

外部から見える状態を整理する

まずは、外部からどのように見えているのかを整理します。
特別なことはせず、いつも通りにスキャンをかけてみるところから始めました。

結果として確認できたのは、次のポートです。

• SSH（22）
• DNS（53）
• HTTP（80 / 32400）
• UPnP（1335 / 32469）

並べてみると、どれも見慣れたサービスばかりです。
その分、最初は「致命的なものは無さそうだな」という印象を持つ人もいるかもしれません。

ただ、少し立ち止まって見ると、気になる点もあります。
DNS や UPnP が外部からそのまま見えており、HTTP も複数ポートで応答しています。
特に UPnP（Universal Plug and Play）が有効な状態で公開されているのは、企業環境ではあまり見かけない構成です。

この時点で受ける印象は、
内部ネットワークでの利用を前提にした機器やサービスが、そのままインターネット側に接続されている、というものです。

スキャン自体は、ごく一般的なオプションしか使っていません。
それでも、これだけの情報が自然に返ってくる。
現場で診断をしていると、「特別なことをしなくても見えてしまう状態」は、実は一番判断が難しいところでもあります。

大きな穴が空いているわけではない。
でも、全体を眺めると、どこか落ち着かない。
この段階で感じる違和感は、あとから振り返ると、だいたい間違っていないことが多いと感じています。

管理画面がそのまま見えるという違和感

Web サービスに対して、ディレクトリをいくつか確認してみます。
ここでも特別なことはせず、よくある手順を淡々と進めていきました。

すると、/admin が見つかります。

この時点で、「ああ、管理画面がそのまま出ていそうだな」という予感はありました。
実際にアクセスしてみると、表示されたのは Pi-hole の管理画面です。

Pi-hole 自体は、DNS レベルで広告やトラッカーをブロックできる便利なツールです。
家庭用ネットワークや検証環境で使われることも多く、決して怪しいものではありません。
私自身も、用途によっては普通に使います。

ただ、この管理画面は、外部から誰でも触れる状態を前提に作られているものではありません。
内部ネットワークで、限られた管理者が使うことを想定したインターフェースです。

ここで強調しておきたいのは、
「Pi-hole が危険だから問題なのではない」という点です。

問題になるのは、

• 内部向けに設計されたツールが
• 内部向けの前提のまま
• インターネットに露出していること

このズレが、静かにリスクを生みます。

診断の現場でも、
「ツール選定は正しいのに、置き場所だけが間違っている」
というケースは本当によく見かけます。

この段階では、まだ何かを“突破した”感覚はありません。
ただ、外から見てはいけないものが、普通に見えている。
その事実だけで、十分に嫌な予感が残ります。

初期設定のまま残っていた認証情報

Pi-hole や Raspberry Pi は、検証用途や小規模な環境で使われることが多い分、
初期設定のまま運用が始まり、そのまま時間だけが経ってしまうケースをよく見かけます。

導入した当初はきちんと把握していても、
「あとで直そう」「いったん動けば十分」といった判断が積み重なり、
気づけば誰も細かい設定を確認しなくなっている。
診断の現場では、こうした背景を感じる環境に出会うことが少なくありません。

この Mirai の環境でも、デフォルトユーザーを使った SSH ログインが可能な状態でした。

何か特別な攻撃をしたわけではありません。
既知の脆弱性を突いたわけでもなく、複雑な手順もありません。
そのまま残っていた設定を、そのまま使っただけです。

この状況が生まれる理由は、だいたい似ています。

• 検証用に立てたまま、本番と同じネットワークに残っていた機器
• 一時的な利用のつもりで作られ、その後の扱いが曖昧になったサーバー
• 担当者が異動や退職をして、誰も触らなくなった環境

どれも、特別な失敗談というより、
忙しい現場ではどうしても起きやすい判断の積み重ねです。

この時点でも、まだ「侵入した」という感覚はありません。
ただ、外から入れる必要のない場所に、普通に入れてしまう。
その事実が、この後の流れをほぼ決めてしまっているように感じます。

権限昇格は“想定内の設定”から

SSH でログインできたので、次に権限まわりを確認します。
ここも特別なことはせず、いつもの癖で sudo の設定を一度見てみました。

結果を見ると、そのユーザーは sudo を使って root 権限のコマンドを実行できる状態でした。
正直なところ、「やはりそうか」という感覚に近いものがあります。

この設定自体は、開発環境や検証環境では珍しいものではありません。
作業効率を優先して、とりあえず管理者権限を持たせておく。
現場でも、そうした判断がされることはよくあります。

そのため、ここでも新しい脆弱性を探す必要はありませんでした。
sudo を使うだけで、そのまま root 権限に到達します。

ここまで来ても、何かを「突破した」という感覚はほとんどありません。
ただ、用意されていた階段を、上から順に上がってきただけです。

振り返ると、この一連の流れはすべて、

• 公開範囲の誤り
• 初期設定の放置
• 権限設計の甘さ

といった、運用面の判断で説明がつきます。

どれも単体では致命的に見えないかもしれません。
ただ、これらが同じ環境の中で重なったとき、外から見える景色は、想像以上にシンプルなものになります。

「消したはず」の情報は、本当に消えているか

root 権限を取得したあと、あらためて環境の中を確認してみます。
ただ、この時点で期待していたような情報は、すぐには見つかりませんでした。

代わりに目に入ったのが、USB ストレージと思われるデバイスの存在です。
外付けメディアが接続されているような雰囲気があります。

Linux 環境では、USB などの外部メディアは /media 以下にマウントされることが多いため、そのあたりを確認してみると、実際に USB デバイス用のディレクトリが見つかりました。

ここで少し気になるのは、
「ファイルとしては見当たらないが、デバイス自体は残っている」という状態です。

ファイルが削除されていたとしても、ストレージそのものには、過去の操作やデータの痕跡が残る場合があります。
Linux では、デバイスを直接確認することで、そうした情報が見えてくることもあります。

「消したから大丈夫」「別の場所に移したから問題ない」そう思っていても、完全に消えていないケースは珍しくありません。

インシデント対応の現場でも、「もう無いはずのデータ」や「残っていないと思っていた情報」から、状況が見えてくる場面によく出会います。

今回のケースも、まさにその感覚に近いものでした。
見えなくなっていただけで、無くなっていたわけではない。
この違いは、後になって効いてきます。

この事例が示していること

この一連の流れを振り返ってみると、派手な攻撃手法は一つも登場していません。
だからこそ、個人的にはとても実務に近いケースだと感じています。

起きていることを整理すると、見えてくるのは次のような点です。

• 内部向けツールが、そのまま外部に公開されていたこと
• 初期設定が見直されないまま残っていたこと
• 権限設計が検証用途のままになっていたこと
• 使われなくなった機器やデータの扱いが曖昧だったこと

どれも、一つひとつを見れば「よくある判断」です。
忙しい現場では、どうしても後回しにされやすいポイントでもあります。

ただ、こうした判断が同じ環境の中で重なったとき、外から見える姿は、想像以上にシンプルになります。
特別なことをしなくても、自然と道がつながってしまう。

今回の Mirai は、そのことをとても分かりやすく示している事例だと思います。

確認されないまま残るものが、一番怖い

この事例には、派手な攻撃手法は登場しません。
だからこそ、実務に近いと感じます。

改めて考えてみると、確認すべきポイントはとてもシンプルです。

• 内部向けツールが、意図せず外部に公開されていないか
• 初期アカウントや初期設定が、そのまま残っていないか
• 想定していない権限を持つユーザーが存在していないか
• 使われなくなった機器やストレージが、曖昧な状態で放置されていないか

何かが起きてから振り返ると、
どれも「確認しておけばよかった」と思う項目です。

予防や診断の立場から見ると、
何も起きていない今こそが、一番落ち着いて見直せるタイミングだと感じています。

一度だけでも、自社の環境を思い浮かべながら照らし合わせてみる。
それだけでも、見えてくるものはきっとあるはずです。

自社のセキュリティに不安を感じたら