［開催レポート］GMO Developers Night#34 / ペンテスターから見た最近のセキュリティ状況

最近のテーマは「監視」です。

監視に検知されずにゴールを達成することもあるし、あとはゼロトラスト環境で端末が監視されていても不足していることが多い。
基本的に多くのお客様はセキュリティ製品を導入、運用している。しかし、そのような製品は今まで出ている攻撃やばらまき攻撃に対してはすごく有効だけど、そうでない攻撃を使えば、技術のある攻撃者なら監視をすり抜けることは可能です。

それもあるし、案件やお客様の要望に応じることもあります。
例えば、お客様の中で我々のセキュリティ製品が本当に稼働しているか確認するために、Emotetのような攻撃を実行してみましょう、ということでテストして評価という感じですかね。ゼロトラスト環境を作ったので評価してあげるという感じですね。
例えばAzureのグローバル管理者を奪取することが最終ゴールの案件であればそこまでたどり着いたけど、監視チームに検知されなかったというのはあり得る話ですね。

あります。ゼロトラスト自体の考え方はモデルとしてはいいんですけど、実現しているベンダーさんや、導入している会社での実装状況によって変わっていったりします。

最近ですと、ゼロトラストといいつつVPNの代わりにVPNっぽいものを入れた製品もある。
あとは、SaaS化されたとか、SSOが実装されたとか、IdP（Identify Provider）としてはAzureやOktaを使っているという例も多い。

一つの例で言うと、セキュリティ製品がいろいろ導入されている端末、仮にEDRとかアンチウイルスとか全部あるという端末に感染ができた場合、外部遠隔操作ができた場合、かつEDRとかも検知されていない場合、通信も判別されていないという状態であれば、攻撃者としては全部SaaSなので、オンプレミス環境がない環境を考えてみると、すべてクラウドになると、すべての業務がクラウドになります、一番守りたい資産、社員の守りたい資産といえばブラウザになるんですね。ブラウザの中のCookie、多要素認証がいろいろ付けてあっても、人は対象のサイトに認証してあるんだったら、多要素認証を通しての形で、そのセッションを我々が取得できたら、外部からもどこからでもアクセスできる。
EDRは、そこの端末にあるからこそ動作するが、我々がVPNのセッションを修復できるのであれば我々の端末から内部に入れるとか、モニターできるツールをすり抜けるいうことも実現します。
ゼロトラストは端末がすべてだから、端末から来るものを全部監視するけど、通信がどう監視されるかは基本的に会社によるというということになります。

対策といえば、セキュリティ製品にすべて頼るというのは、現時点では見たことないです。
多少カスタムなものを作って、仮にChromeを使っている場合はChrome以外から使うことがないので、Cookieに触れた瞬間に監視してアラートを出すといったものを作るとか、現時点では有効な感じ。そのあとの話となると、不審アクセスのような感じでCookieが取られて、攻撃者であればあちこちにアクセスするとか、例えばAzureEDのようなIdPに外部からアクセスしてしまったとか、感染した端末を踏み台にすればIPアドレスも変わらないけど、外部からいきなりアクセスした場合はIPアドレスが変わる、といったような、細かいログを解析して不審だなといったのを見ていくしかないと思う。

こうなってくると、SaaS側ですべてのログを収集しながらやるという必要があるし、boxなどのクラウドストレージの場合は、いきなりいろんなファイルにアクセスしてダウンロードし始めたということならある程度見られるぐらい。

対策が大変なのは、SSOみたいな感じで各サイトに認証するじゃないですか、SSO自体の対策としては、例えば各サイトにアクセスするにはまたIdPとか多要素認証、一番よければYubiKeyみたいなFIDOがあってさらに認証しなければいけないという導入ができるのであればよいが、ただし認証済みのセッションが取れるということは、基本的には、各サイトのCookieの有効期間がサービスによって異なるので、例えばAzureのSSOのCookieの有効期間を1時間とすればそれは1時間で切れるが、BOXやDropboxなどのほかのサービスでは1か月とか無限とか異なるので、そのあたりのコントロールは、ユーザー側、システム管理者側にはないので、そこがちょっと大変。

我々のゴールはいろいろあるけど、やり方もいろいろあって、例えば感染済みの端末からスタートするとか、外部公開されている情報を探してそこからエントリーポイントを探しに行きます。両方とも外部の情報を集めるので、Gitから始めることはあります。

会社名を入れるとかいろいろ検索して、何も見つからない案件はほぼなく、そもそも企業の中に開発者がいない案件ぐらいかもしれないですね。あっちこっちに認証情報がどこでもあるというわけではありませんが、情報収集という意味ではかなり役に立つものがあります。
昔の事例でいうと、Gitってなにが悪いかというと、何か間違えてアップロードした後に消しても、コミットが消されていない状態であれば、誰でも履歴から過去のコミットを見て情報が得られるので、ある案件では、鍵が取れて、鍵から外部のサービスにAPIキーで入れて、そこから内部情報が取れたというケースがあります。

あれは、開発者というよりは開発者のインターンが会社に入ってDropboxのリンクをメモの中に入れていて、Dropboxのリンクに入ると、機密情報が誰でもダウンロードできる状態だったのでかなり大変でしたね。

そうですね。プレミアムサービスに加入しなければ、基本的にアクセス経歴とかも取れない。

結構あります。特にオンプレミスのドメインがあるとファイルサーバーもあるので、「平文パスワードの管理」「共通パスワードの管理」「脆弱なパスワード」が報告書の中のTOP3。
たぶん最近はクラウドのみの環境になってきて、みなさんがパスワードマネージャーをきちんと使うようになってきて、少なくはなってきた。
でも、やっぱり大企業やオンプレがある環境とかだと整理が大変だし、昔ながらのやり方で残していることが多いです。

そうですね。平文パスワードはないにしても、基本的に我々がゴールとするシステムが、仮になにかしら特殊に作られたシステムにしましょう、そのシステムのパスワードが毎日変わるわけでもないし、たぶんいつか作られてずっと運用されている形になるので、どの会社でも「納品物」みたいな感じのフォルダがあるんですね、そこに仕様書があって、その仕様書の中にパスワードが書いてあるとか、それで半分以上のパスワードが取れるという感じ。

納品されてからパスワードを変えていればいいけど、そのままなので…。隣りに変えてはだめと書いてあるので。

SSHに関していうと、そもそもSSHで鍵を使って認証しているのであれば、かなりいい方という感じ。
それにYubiKeyで二段階認証があれば、おお、すごいという。
となると、基本的にそのサーバーは対象にしない。ゴールを達成するためには絶対にその経路を通るということは必要ないので、ほかを探すことに決めます。
パスワードが分かっているSSHの証明書だったら、それはちょっと解析してみてみるとか、あとは社員個人のアカウントだったらそれで入ってみるとか、牧田さんと一緒にやった案件では、ある鍵ですべてのサーバーに入れたというところもありました。

ほかのAPI鍵とかAWS鍵になってくると、今でも外部と内部という感じがあって、例えばある会社だと内部はセキュアという考え方で、その中では内部のGitがあって、内部のGitはそもそも認証なしでエクスプローラですべてのプロジェクトが見れたりして、それが内部だから鍵がそのままハードコードされていたりするのもあります。

そうなると、アクセス制限ができてない会社がかなり多い。要は、開発者であってもアクセスできる領域がどこまでかを決めなければならないはずだが、何でもかんでもできるとか、一般社員で営業なのにGitに入れてプロジェクトをクローンできるとか、認証なしでイメージをとれるとか、そこからいろいろ鍵をとって本番環境まで至ってしまうこともあります。

あとは、会社によっては、物理的にセキュアエリア、セキュアルームを作っているけど、論理的にはそこのネットワークに入れてしまうとあとは信頼性の高いエリアということで二段階認証もなにもないということもあります。
オンプレ環境で横展開してしまうと、監視に気付かなければずっとそこにいて何でもできるという状態になります。二段階認証を破らないと入れない環境だと、かなりできてるな、と喜ぶ。しっかりやってるなと。

結局、緊急用の手順書や鍵を置いてあるところは仮にファイルサーバーとして考えても、ファイルサーバー自体がおそらく信頼のあるユーザーしかアクセスしないと考えられているかもしれないけど、ある権限までは入れてしまう、確かに物理的に行かないとどこかに入れないけど、手元に緊急用のVPNの認証情報がなんでもあるから、それを使い回してつなげばよいというのもある。もちろん繋げる時間を決めてあるかとか、繋がった途端監視されて切断されるとか、会社によってはプロセスがあるはずだけど、一番悪いシナリオでは、何も気付かれず監視されずだったらそこにまで入って終わってしまう。

通知はすごくいいと思います。
特に管理者側におすすめなのは、資産管理、どこに何があるかとか、そのシステム自体にはどのように入れるかを把握しておく、彼らが自分で考えて作った経路はあると思うけど、我々も中に入って社内wikiとかを読んで、正常に入れる経路を把握する、それがイコール我々がその経路を通ると検知されてしまう、だったらそれを通ってはいけない、だから同じサーバーなり同じシステムに、ほかには入る経路は何があるかとか、管理者自体がどんなふうに入ってメンテナンスするかを考えてみて、それを利用してしまうと実はそこには検知やアラートを出す仕組みをわざわざ入れてない、あるいは忘れたということがあって、最終のところまで入れてしまうということもある。検知を回避するという意味では。

それはいいですね、ハニーポット的な。

その次のステップを考えないといけなくて、どこからやられたかとか、次に何を確認すべきか、という演習。IR（Incident Response）的な。要は、端末をネットワークから取り出さないといけないけど、どのくらい時間がかかるとか、ユーザーが高権限のアカウントをハニーポットにしてある場合は、高権限のアカウントで実は横展開されてしまった可能性はなないか、どういう風に実装していたかにもよるけど。

でも、どのアカウントでも作っていいというわけではない。ある会社で、ダミーアカウントを作りましたと、でも、どう見てもそのアカウントを使いたいという気持ちにならなかった。なぜかというと、権限も何もなにもない、ログインした経歴もない、パスワードが弱いかもしれないがそのアカウントが取れたところで何も変わらないという。

確かになんとかアドミンというアカウントだったけど、どうみても権限がなさ過ぎて逆に怪しいということは侵入者からは見えるんです。
生きているかのようなアカウントで、多少権限があって履歴があるようなものを作ってあげないとすり抜けてしまう。

最近、かなり多いですね。
クライアント証明書、ウェブアプリとか、個人的にはすごくいいと思うけど、その認証はその証明書をどんなふうに保管するかいうのが大事になってくる。
WindowsのマシンであればTPMで保存している場合は基本的には現時点では安全ですね。
どこかにはまだ公開されていない攻撃があるけど、少なくても今のところはTPMからの証明書の奪取ができない状況ですね。

ただし、TPMじゃなくて、ファイルとして保存してあるとか、スクリプトプロバイダーとかほかの形で保存してあるとかであれば、システム権限さえとれればWindows端末から証明書の奪取ができてしまうのが現実です。
Macの端末の場合は違っていて、MacはKeychainというものがあって、ユーザー側とシステム側のKeychainがあって、ユーザーのセッションに会社から遠隔操作ができる状態になっていたら、基本的にはすごく簡単にダンプしてしまうということができる。
システム側のKeychainに入っている場合は、ユーザー自分自身でルート権限でGUIから取るしかないのでまだ安全。

大企業の場合はどこかに集めてそれを配布するんですけど、全部バックアップ用に証明書が置いてあるとか。

我々がやってる侵入の中では、Linuxにエクスプロイトを使って侵入するというケースはかなり少ない。基本的に運用や設計の問題で何かしてしまおうということが多くて、Linuxへアクセスするなら普通にSSHで一般社員がやるような形でかつバレない形にします。
外部の場合は、例えばあるサービスが脆弱でそれを利用するということはないことはないけど、かなり少ないのかなと思います。

例えばリバースシェルがとれて、そこから侵入しようとすると、SE Linuxはかなり邪魔になるけど、そもそも我々が得たいなにかしらの目的にはSE Linuxを突破する必要性はないことが多い。必要であれば頑張るしかないし、別に触らなくてもいいという時もあります。

我々の目的が何でもかんでも侵入していくのではなく、会社の資産、クレジットカード情報、個人情報だったりソースコードだったり、これを入手するということなので、経路は何でもいいということもあるんですね。ムリにそこを通らなくてもいいと。

大体同じ割合です。
ただ、ゴールが何になるかで変わったりする。ドメイン管理者を取ることがゴールでそこで終わるケースもあるし、守りたい資産、データへ入れるかどうかというケースもある。侵入はどちらも成功しているので確かに9割以上になるけど、データの取得まで頼まれたところで、できなかったことはほぼない、といえます。

簡単に言うと、時間と予算の問題もあるので、我々が例えばスコープとしてフィッシングも入れますか、内部フィッシングを入れますかとか内部IRを突破しながらやりますかとか、IRに捕まったらどうしますかとか、無限の質問があるんですけど、IRに捕まったら無意味みたいなシステムの脆弱性だけを見るんだったら短縮の時間でいろいろやってできましたということを見せればいいし、IRが強いとかいう会社ならば、じゃあIRのままでやってみましょう、捕まることは可能か不可能かというところを見てみましょうというケースもある。

はい。例えば社内のSOCがあるとか、誰かレスポンスできるような守り側のチーム、セキュリティチームみたいな人たちがいるとか、アウトソーシングしている、委託のSOCがいるとか、いろいろあったりする。

セキュリティ＝ユーザビリティではないからですね、残念ながら。

ハッシュの種類によるけど、Windowsであれば我々のサーバーなら数時間。

パスワードマネージャーも端末で実行できるんであれば、ダメかなと。
ものによって、例えばシステム権限で動いていたりするので、権限昇格をしない限りはまだマシであったりすることもあるんですけど、我々がやるときは権限昇格が必要だったら、必要に応じてゼロデイを探して出してやるというところもあったりする。
時間が許す限りはやれるけど、テストの期間はそれほど長くないので、3日程度で見つけられるのなら探すんですけど、それ以上かかるものは期間内には触らない。

あとは多要素認証について追加で言うと、各サイトに与える認証とかがあると便利だけど、SSOはあるにしてもその中で多要素認証みたいなものを実現できるのであればいいと思ったりして、例えばAzureのIdPを使って、いろんなアプリケーションにテストするけど、それはそれでよいけど、ただし、何を追加して欲しいかというと、例えば一部のアプリを絶対に守らなければいけない、例えばAWSの管理コンソールとかAzureの管理コンソールとかがあったりしたら、そこだけに例えばFIDOの確認を追加する、SSOされるときにはそこにアクセスする瞬間、多要素認証を聞かれる、多要素認証もできる限りFIDOにする、というのを個人的におすすめだと思う。