この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
今回はCODE BLUE 2022で行われた以下のセッションのレポートです。
5Gネットワークのハッキング
5Gネットワークを構築するためには、2つの選択肢が存在する。1つは既存の配備を拡大する方法。もう1つは根本的に新しい方法で構築する方法だ。どちらの選択肢も、セキュリティに大きな課題をもたらす。 ここでは、より先進的な設計に焦点を当てながら、双方のタイプの5G導入におけるセキュリティの課題について考察する。最新のモバイル・ネットワークは、クラウドネイティブで高度に自動化されている。ネットワークにおいては、Dockerコンテナとオーケストレーション・ツールが急速に導入されている。 クラウドのハッキング技術は、モバイルネットワークと密接な関係をもたらす。同時に、標準なITセキュリティ管理は、通信事業者の環境ではまだ実装が難しく、保護のギャップが拡大している。 本講演では、標準的なハッキング技術が通信事業者のネットワークにどれほど通用するのかを示す一方で、標準なITの防御策がそれほど有効ではない可能性があることをあきらかにする。
Presented by : カールステン・ノール - Karsten Nohl
レポート
- 3年ぶりに集まれて嬉しい
- 4Gから色々あった
- 新しいテクノロジーが出るたびに脆弱性がでる
- 5Gのケーススタディ
- 他のテクノロジーでも役に立つ
- みなさんのシステムでも
- クラウドを使っていたり
- 自己紹介
- グローバルセキュリティハッカー
- モバイルネットワークを中からセキュアにする手伝いをしている
- いつも何かを壊して構造的に修復することが大好き
- 5Gの話
- いろんなバージョンの5Gインフラがある
- いつから始めたかで異なる
- 日本の3社は4Gネットワークに5Gアンテナを展開
- テクノロジーは変わらず帯域が変わるだけ
- 4Gのリスクが残る
- 楽天は1から
- レガシーなものはない
- ネイティブ5G
- コアや無線も5G
- オープンとそうでないものもある
- レガシーから始める
- 最近は強化されている
- 2Gはアンテナだけでハッキングされている
- なりすましやDoSなど今は難しい
- まだリスクはある
- WiFiもある
- モバイルネットワークは5Gでもっとセキュアになるようにアイデアが導入されている
- しかしなりすましや通話を盗聴したりされる
- 5Gの標準は前より良いはずなのに
- 2Gと一緒にSS7が導入されていて、SS7はまだ利用されている
- 今回はテクノロジー中心の話
- 現状
- 4Gから5Gにアップデートされている
- 認証が弱かったり
- ITネットワークとして弱い
- 90年代の仕組みが残っている
- あらゆるものを遮蔽しようとしている
- 何が変わってきているか
- クラウドやコンテナが使われている
- 自動化もしている
- 5Gは低遅延
- ユーザーに近いところにデータセンターがいる
- もともとはゆっくり増やしていく
- 5Gでは500のDCが複数の機能を果たしてコンスタントに変化し続ける
- スマートエッジ
- カスタマーに近いところで処理される
- 5Gでは構築しなくて機能を展開する
- モバイルネットワークはクラウドで構築され自動化されている
- 少人数で自動化スクリプトに手を加えて変更していく
- 仮想化の影響
- コンテナはKubernetes
- 理論的にはセキュリティが強化されていることになる
- それぞれがサンドボックスになる
- 強い成約がかかる
- 前はフラットなネットワークにいた
- しかしコンテナやKubernetesから抜け出すことができれば大きな権限を入手できる
- Dockerコンテナでエスケープが起きやすい
- コンフィグが多い
- 攻撃が起きやすいものがある
- 特権コンテナ
- 直接カーネルにアクセスできる
- hostPIDはかなりよく散見される
- プロセスをkillできる
- ネットワークアクセス
- 通常はホストにブリッジする
- Kubernetesはインターフェイスを共有している
- ブリッジするだけで多くの通信がネットワークキャプチャできてしまう
- 暗号化されていないものも多い
- 最終的にクラスタ全体を乗っ取られることも
- Kubernetesにシフトしてやることが増えているがみんなできていない
- コンテナはKubernetes
- 自動化の影響
- 排除できたこともある
- 自動的に置き換わるため
- 偶発的な情報の漏洩
- パブリックな場所に乗せてしまったり
- 排除できたこともある
- Red Teamの演習
- 犯罪者と同じ立場で実施
- 1社だけではない、色んな会社の結果
- まずお客様に対するスパイ行為
- ポータルサイトがセキュアではない
- コンテナから抜け出してKubernetesがアクセスできるものすべてにアクセスできる
- モバイルネットワーク側に行かずにキャプチャできる
- デバッグログを見つけたら色々できる
- 認証情報やDWHを見つける
- 電気通信網外にあるが顧客情報が見れる
- 統計もある
- オンラインバンキングや2FAを取得できる
- プライベート情報アクセス
- 内部のソースコードリポジトリ
- 本来はここに入れるといけないが、新しいマシンに展開している情報を取得できる
- 初期の入力情報を取得
- 電気通信網ではなく取れる
- 最後までモバイル通信網に入らなくてもできる
- 修復する
- コンテナを修復
- コンフィグを変える
- 比較的カンタン
- CI/CDでやっているはず
- テスト環境も大事
- テストと本番の環境は曖昧になる
- 他の内容はもう少し難しい
- 人々はゼロトラストと言っている
- 実装は難しい
- ボトムアップでやらないといけない
- 基本的なところに戻る
- パッチをあてる
- 管理アクセスを制約
- モニタリングする
- あまりにも古い話
- また再びこれを考えないといけない
- 古い環境も維持しないといけない
- SUSEだからいいとかはない
- ベンダーが全然提供しないこともある
- 年に2回程度しかやっていないとかだめ
- 今後モバイルネットワークはずっとパッチされなくなる
- 隔離するがコンテナの問題につながる
- コンテナのアクセス管理と特権管理はどんな業種でもやる
- ハッカーと特権アクセスを仲介するものがいる
- 最近はOSSがある
- PAMを持っていないところもある
- 今は無料でできるからやろう
- モダンになっているので難しい
- EDRを使う
- オープンソースもある
- ある程度は止められる
- セキュリティツールをインフラ用に用意する
- クラウドになって難しくなったものもある
- セキュリティのコンピテンスを加えることを忘れずに
- 新しいものが加わっているので多くのセキュリティテストが必要
- コンテナを修復
感想
セキュリティの原理原則と同じように、ITセキュリティ基礎を徹底する必要がありますね。
コンテナセキュリティも引き続き注視したいです。
32
