侵入経路を白日の下にさらすペネトレーションテストで、自社環境をよりセキュアに

イエラエセキュリティの顧問を務める川口洋が、イエラエセキュリティを支える多彩なメンバーと共に、サイバーセキュリティやサイバーリスクの今を語り合う座談会シリーズ、第13回をお送りします。

川口洋氏は、株式会社川口設計 代表取締役として、情報セキュリティEXPO、Interop、各都道府県警のサイバーテロ対策協議会などで講演、安全なITネットワークの実現を目指してセキュリティ演習なども提供しています。

イエラエ顧問として、「川口洋の座談会シリーズ」を2019年に開始。サイバーセキュリティを巡る様々な話題を、社内外のゲスト達と共に論じ語ってきました（川口洋の座談会シリーズ)。

前回から2回にわたり、イエラエセキュリティの高度解析部 ペネトレーションテスト課の課長で、執行役員でもあるルスラン・サイフィエフと、同じくペネトレーションテスト課の「黒林檎」こと村島正浩を迎え、イエラエセキュリティのペネトレーションテストの実際について、顧問・川口洋が詳しく聞きます。どうぞお楽しみください！

前編はコチラ

【緊急開催決定！7月31日 川口洋座談会ウェビナー実施します！】

お申し込みはこちらをクリック

クラウドサービスの認証管理はログインセッションで突破

川口洋（以下、川口）：ペネトレーションテストで、端末から侵入して、ターゲットがサーバー群の場合に、サーバー群がオンプレである場合とクラウドの場合がありますよね。クラウド側の方に置かれたサーバー群に侵入できるかといったチェックもするんですか？　クラウド型になると、それはそれで、またいろいろ課題がありそうに思うんですが。

村島正浩（以下、村島）：僕自身はクラウドの案件は数は少ないですが、Azure ADになってる場合が多いですね。ファイルサーバーに自由に出入りできるようになると、クラウドサーバーに入るための認証情報とかも保存されてたりしています。侵入したマシンにOneDriveが割り当てられていたら、そのフォルダを見たりして、そこに認証情報が保存されていたりする場合は問題として記載します。実際、エクセルにAWSのパスワードが書いてあることもありましたね。

サイフィエフ・ルスラン（以下、ルスラン）：会社によってファイルサーバーの大きさも全然違いますので、一概には言えないのですが、数百テラバイトもあるようなサーバーでは検索はすごく大変で自動化した場合も検知されやすいので、手作業で面白いフォルダがないかを探していったりします。

クラウドだと、その人がアクセスできるフォルダがかなり限定されているといった問題はあります。あと例えば、外部からアクセスの場合は二段階認証が必要だけれど、内部からは必要無かったりもします。二段階認証の設定次第で違ってきますね。でも、基本的には突破できるところが多いです。

村島：侵入したパソコンのログインセッションを持ってくることが多いですね。

ルスラン：それが基本かもしれないですね。

川口：Azure ADで条件付きアクセスをきっちり設定できているかどうかって難しいですよね。クラウドベンダ側がそのような機能を提供していても、それをきっちりデプロイして運用を回せるかというと、結構大変なことだなと思います。

ルスラン：条件付きアクセスは、環境の大きさや今までの設定プロセスなどによって、設定できることが変わったりもします。きちんと設定されているなと思う会社の環境であっても、やはりたまに設定不備や運用不備などが残ってしまうこともありますね。

川口：設定不備と運用不備って、重要ですけどなかなか見つかりにくいですよね。

ルスラン：社内の人達に知識が無いと、見つけるのは難しいですね。とはいえ最近はブルーチーム向けにいろんなツールも出ているし、レッドチーム向けに作られたツールをブルーチームが使えば同じ内容が確認できて問題を潰すことが出来ます。お互い使うべきツールは出ているので、あとはそれを調べるか、知っているかどうかですね。

川口：SlackやOffice 365のようなクラウドサービスもありますが、これらのサービスに入っていいですよと言われた時は、どうやってチェックするんですか。

ルスラン：外部から侵入して認証情報を取得出来て、その会社がOffice 365やGSuiteを使っていたりSlackやBox、OneDriveなどのサービスを使ってることが分かれば、そこで認証してみることはありますね。二段階認証が無い場合は簡単に入れますので、お客さんの設定次第ですね。二段階認証になっているような場合は、かなり侵入が難しくなります。

川口：二段階認証は必須だと思いますが、やってない会社も多いんじゃないですか。感覚的にどうですか。

村島：イエラエに依頼された案件を見ているだけなので偏りはあると思いますが、二段階認証をしないでIP制限だけしているお客さんも一定数いますね。

ペネトレーションテストは脆弱性を潰す“ツール”のひとつ

川口：二段階認証も設定していないのに、ペネトレーションテストを依頼するお客さんがいるんですね。その心理が実のところ、よくわからないんですけど……そんなお客さんがわざわざペネトレーションテストに予算を割くものなんですか？

村島：ペネトレーションテストを依頼する理由としては、「経営層に対して予算取りをするため」ということは多いですね。「現状このような経路で侵入されて、このようなリスクがあります」と提示するためのツールとして、経営に関わる部門の人がペネトレーションテストを依頼されます。ペネトレーションテストで脆弱性が明らかになった後は、それを根拠にCSIRTやSOCの為に予算を取られていることが多いですね。

ルスラン：脆弱性診断の場合は「対象の100ページをテストしてください」という形での依頼に対して、チェックリストでのテストをしていくことが多いですよね。脆弱性が存在するか、幅広く自動スキャナと手動を組み合わせてチェックすることが多いです。一方でペネトレーションテストはサブドメインがあるか、ステージング環境があるか、会社がテスト対象と考えている100ページ以外にページがあるのを見つけて、そこに脆弱性がないかどうか、侵入経路を目で見て考えて、出来るかどうかを試していきますので、全く視点が違うサービスなんです。

会社のセキュリティは基本的に「ソーシャル」と「物理」と「デジタル」の3つを組み合わせて考えるべきだと思います。例えば人の“脆弱性”を使用して、別のルートで認証情報を取得できたりもする。これが「ソーシャル」の観点です。更に、その会社に物理的に入ってしまって、対象の人物の端末を盗んでしまうシナリオもありますし、社内のWi-Fiをハックしてそこから侵入してみるパターンもあります。これが「物理」の観点です。ペネトレーションテストは基本的には「デジタル」検証のパターンなんです。

川口：物理、ソーシャル、デジタルという3つの観点は大事ですね。

ルスラン：一言で“フィッシング”といっても、実際はどの人が実行してくれるかということが重要なポイントだということはお話してきました（本座談会前編を参照）。マルウェアやフィッシングの被害等は、EDR等のツールでSOCが検知することは出来るかもしれません。

でも、会社全体のことを考えるべき立場のレッドチームとしては、基本的にゴールへの達成するルートは何でもありです。ですから、「うちの会社の人達はこういうことがあったらどう対応するか」「SOCがどう対応するか」「想定したゴールまで辿り着けるか」「どんな侵入方法があるか」などを知りたいんですね。ですから、場合によってはテストも「物理」や「ソーシャル」を含むことがあります。

ペネトレーションテスターとしては、「今回はこのようなルートで侵入できました」とか、「こんなミスがありました」とか、「このプロセスの対応ミスがあった」とか、そういう報告をして、それを元に色々修正をしてもらい、その後改めて別の案件としてまたテストをご依頼いただきテストをする、というサイクルを繰り返し続けることになります。

村島：金融系のお客様に関しては、ネットワークの分離が適切にされているか確認しなければならないという業界固有の事情もあり、それが出来ているかテストを依頼されることが多いですね。

川口：物理的にも論理的にも分離されていればいいんですが、意外とくっついてたりしますよね。偉い人は物理的に線が繋がってないと思っていても、いやいや、線は繋がってますよってこともあります。

ルスラン：論理分離でうまくできるパターンはもちろんありますけど、そこをミスしてしまうと全く分離できてないことになってしまいますね。

村島：どこかしらのサーバーのコンポーネントが連携していることは多いです。管理が難しくなりますからね。

脆弱性診断とペネトレーションテスト、手法の違いとスコープの違い

川口：世間では、サブドメインやステージング環境の利用でテスト環境が侵入されて大騒ぎしていますよね。自分が侵入されたらと思うとゾッとします。ペネトレーションテストは機能制限とか、「ウェブサイトのここだけお願いします」という、いわゆる脆弱性診断とは違って、そういうところのチェックがスコープに入るのが特徴ということでしょうか。

村島：ペネトレーションテストも、開発段階で依頼されると、テスト開始直前に「全部テスト対象にしようと思ってたけど、この機能だけでお願いします」となる場合もあります。テスト対象が100から1になるような感じですが、その残った「1」で、山ほど脆弱性を見つけた、ということもありました。

ルスラン：別の会社で働いていた時「この機能を開発したので、他の部分は見ないでください。ここにあるボタンも押しちゃダメです」というような制限のある形で脆弱性診断を依頼されたことがあったんですね。でも、依頼内容ではない範囲で脆弱性を見つけてしまうこともあるんです。お客さんによっては、その報告を喜んでくれたりもしますが、8割位はすごく怒られてきましたね。「なんでそんな所をそもそも見ようとしたんだ」とか。会社全体のセキュリティのことを考えていないなと思っていました。

そういう意味では、ペネトレーションテストは全然違います。公開されている資料を元にテストしたり、チェックリストを作って確認したりしても何も脆弱性が見つからないこともありますが、ペネトレーションテストであれば、ファジングだったり、WebSocketのフレームワークが使われていそうだ、と当たりを付けてから資料を読んで、「ここに隠し機能があるんじゃないか」等含めて深掘りしていく形なので、手法も違います。

村島：通常のウェブ診断だと、WebSocketって診断しにくいポイントですけど、ペネトレーションテストだと見つけられたりしますね。

ルスラン：「ペネトレーションテスト」といっても、実際にはどこからどこまでが範囲なのかは場合によって違います。どこからスタートしてどこまでやるか、スコープをどこまで広げるかですね。

川口：脆弱性診断とペネトレーションテストが違うものだっていうのは、この座談会を通じて世の中に広まっていくといいなと思います。あと、ペネトレーションテストを受ける時にスコープをどうするか考えるのは、重要なポイントだと思うんですよ。

村島：確かにスコープの決め方は、難しいかもしれませんね。

ルスラン：昔あった案件で、お客さんはあるサブドメインだけテストをして欲しいと考えていたらしいんですが、うまく意思疎通できていなくて私は会社全体に対してテストをしてしまったんです。数時間調べた段階で、ある開発者がテストでGitHubを作っていて、入社時に社員に行ったセッションの資料を置いているのを見つけました。

会社が何をしているかというような資料に加えて、Dropboxのリンクがあったんです。そこには誰でも見られる状態で、その会社が作っている製品を説明している動画が、30時間分くらい置いてあったんです。それを報告したら大騒ぎになってしまいました。依頼されたところだけを調べていたら、見つけられなかった問題点ですね。

村島：他にも、例えばモバイルアプリ単体のテスト依頼が来たりした場合に、クライアントが選定してきた「モバイルアプリが通信するAPIリスト」を元にウェブ診断してみたら、実際のモバイルアプリにはそのリストに無いAPIがある…というようなことは起こったりしますね。

「見なければ永遠に気付かない」ログ監視の重要性

川口：モバイルアプリも、ペネトレーションテストの過程で必要だったら解析するんですね。

ルスラン：モバイルアプリそのものがスコープに入っていることもありますし、入っていなくても、会社の出しているアプリケーションがあればそれを解析して、通信していそうなところを見つけたりもします。

川口：アプリの通信先で、保有サーバーが分かるってことですね。

ルスラン：そうですね。それに加えて、例えば会社がどのようなクラウドを多く使用しているか、自社のサイトをどこに立てているかなどの情報を調べます。それによって、例えばC2通信――信頼性のある通信方法を使ったドメインフロンティングが利用できることがあります。

簡単に説明すると、攻撃者はクラウドプロバイダーのCDNの仕組みを悪用して通信を行います。自社内から見ると信頼性のあるAWSやAzure等のドメインのCDN環境にデータを流しているので、安全な通信に見せかけられていますが、実際は攻撃者のサーバにリダイレクトしているんですね。

川口：随分と手が込んでいますね。DNSの通信に偽装するケースもあるんですか。

ルスラン：これは単純に通信を見るだけでは判別できません。どこの端末からどのような通信が出ているのか見る必要があります。「これまでは対象のドメインにアクセスが一切なかった」「アクセス数が多い」「定期的にアクセスが行われている」などを監視するのは一つの方法になります。

また、攻撃者は端末に侵入したら、何かしらの行動をしますよね。情報を取得する、特権昇格する、横展開する、あるプロセスにインジェクションする、実行する等々……、外部通信に加えて、これらのアクションを総合的に解析や把握できるかどうかがポイントになってきます。早めに把握できれば、その端末を止めたりすることも出来ますから。

村島：通信速度が非常に遅いので、メインで使うことはないですけれど。

ルスラン：基本的にはそれしか使えない時に使う手法です。他にも、サーバーセグメントになっていて外部通信ができないはずなのにDNS通信が実はできているということであれば、そこに対してマルウェアを実行させてもらって、DNS通信ができるかを見たりします。それとは別の問題として、そもそもDNS通信の把握ができているか、というチェックもします。

川口：DNSって掴みにくいですよね。ログも取ってないし。

ルスラン：DNSは意外と簡単だと思います。SplunkなどのSIEM（Security Information and Event Management）も色々ありますし、DNSの通信内容を監視していれば、一般のDNS通信とは全く違うパターンになります。通信量も多くなりますし、遠隔操作するために内容も変わってくるので、正しいルールを開発すれば意外と簡単に見つけられます。

川口：見ようとすれば、ってことですよね。

ルスラン：もちろん、見ようとすれば、ですね。見なければ、永遠に分からない。

川口：DNSの通信を見てるって話はほとんど聞かないですね。真面目にやってるところももちろんあるんですけど。

ルスラン：SOCがそもそもこのような通信方法を把握しているかどうか、という問題もありますが。

川口：SOCの人めちゃくちゃ大変ですね。

ルスラン：そうですね。EDRやアンチウィルスのログ解析も大変ですよね。例えば、ある端末のログが突然来なくなった時に「端末がシャットダウンされたのか？」「EDR/AVのプロセスが死んでいるのか？」「EDRのログは来てないけど、アンチウイルスのログは来ているな」といったことのチェックが出来るように普段から検知のルールを作って監視しておけば、把握できることは増えます。ルールがあっても、実際にSOCがどう動くか、どう検知しているかをチェックする場合、どの程度解析してるかどうかは大事なポイントになります。

川口：侵入を止められなくても、ログを解析できれば、何が動いてプロセスがどうなってるか…状況はわかりますからね。

ただ、EDRやアンチウィルスのセキュリティ製品って、管理者権限や特権で実行されることが多いので、そこを悪用されると非常に厄介ですよね。管理されていなければ、ペネトレーションテストする側にとって“使える”ツールってことになってしまいますね。

村島：過去に横展開が難しかった時は、その方法を使ったこともありますね。

ルスラン：セキュリティ製品の中に脆弱性があれば、その端末で特権昇格が出来たりしますので、それをうまく利用することはあります。ただ、どの製品でも有り得る話なんですが、お客さんがパッチのマネジメントを出来ていないという、別の問題もありますよね。

川口：パッチマネジメントをサボっている会社は結構あると思いますよ。セキュリティ製品のパッチマネジメントすらされてない会社もあると思います。

村島：実際に「パッチマネジメントをしてくれる製品はないですか」っていう問い合わせは多いですね。

川口：アップデートボタンを押しているだけで良いものはともかく、メーカーのウェブサイトからアップデート版を新しく取ってこないといけないものは、漏れてるケースが多そうです。

ルスラン：最近、Windowsアップデートは結構きちんとしてらっしゃる会社が増えていますが、サードパーティーの製品はどうしようも無い時があるんですね。どうしてもある製品が使いたくて、かつ管理者権限で動かしている場合に、その製品に脆弱性があったりすると、すぐに特権昇格されてしまう可能性があります。それをなるべく防ぐため、その製品がどこまで管理されていて、ちゃんとパッチなどが与えられているかが大事になってきます。

村島：自分のクライアントマシンのアップデートを完全に管理できている人って、そんなに多くないと思います。

川口：自分のパソコンには余計なソフト入れたくないなって思いますね。

ルスラン：とはいえ、もちろんEDRはあったほうがいいですよ。アンチウイルスの役割は入れないようにすることや実行できないようにすることで、EDRは侵入された時に早く見つけることが目的なので、セットで使うべきだと思いますね。

「自社環境をセキュアにしたい」という気持ちに応えたい

川口：ペネトレーションテストを受けようという会社は、なかなかの覚悟を持って依頼してきますよね。対策がパーフェクトで、イエラエ側が「全く動けませんでした」ってことはほとんど無いわけですから、大概侵入されて色々指摘されてしまうわけですよね。

ルスラン：あまりにもテスト期間が限定されて、対応時間が全然無かった時はありました。細かいレギュレーションが色々あって、それに基づいてやらないといけないとか。脆弱性を見つけると怒るとか。突破できると向こうからクレームが入ったりして。それは本当に大変です。

川口：言い訳のための“セキュリティ“をしている典型的パターンですね。

ルスラン：こういうレギュレーションが細かいお客様からの質問としてよくある質問は、ものすごく最低限の対策を入れて、「これで大丈夫ですか？」と聞かれることです。「このアカウントは削除できないんですが、この裏道でも大丈夫ですか」と聞かれたり。ちゃんと直すことはせずに、なんとか直してる風にしたいとか。たまにですけど、直せないこともありますしね。正規の直し方はできないけど、裏道的にどう直すか相談されたりして、答え方が悩ましいです。

川口：直す気がないのになんでペネトレーションテストを受けるんだろうと思いますが、世の中にはそういう会社も沢山あることを知ってるので悩ましいですね。

ルスラン：もちろん、環境によって、ビジネスプロセスなどが絡んできて、会社さんとしては本当に直したいと思っていても、正規の直し方ができないところもあります。ビジネスプロセスと繋がっているパターンだと、実際に直すことそのものが結構難しいということもあります。インフラはそこまで影響がないことが多いですが、会社のプロセスは長期間止められないので、どうやって直していくか考えたりもします。

川口：ある会社さんなんかは、ルスランさんに侵入されたことを喜んでましたけどね。「ルスランさんに侵入されたから、報告会が楽しみなんです」って。いいパターンだなぁ、と思うわけですよ（笑）。どうやられたかも大事ですけど、報告会って重要な場ですよね。

村島：弊社の場合、ペネトレーションテストは基本的に報告会を行なっています。レポートを出して、コンサルティングの部分で報告会が入る形になりますね。ルスランさんが出席すると、だいたいクライアントさんは喜びますよね（笑）。

ルスラン：そうですね（笑）。自分がやったことやシステムのことも話しますけど、その場で出てくる質問とか意見に対して、そこで話せるのがいいですね。その場で質問もらえたらすぐ対応できることもありますし。

村島：メールでは質問が来ないけど、報告会で質問が来るというパターンは多いですね。

ルスラン：「自分の環境をもっとセキュアにしたい」という気持ちがある会社はいいですね。話しやすいですし、脆弱性を見つけると感謝してもらえるし、「もっと相談に乗ってください」って言って頂けますし。やりやすいです。

川口：最後に、ユーザーさんに気をつけて欲しいことを1つだけ話してもらえますか。

ルスラン：パスワード管理をしっかりして欲しいですね。1番簡単ですから。パスワード管理ができないと、色々大変なことになってしまいますからね。せっかく会社のパスワードポリシーは良くなっているのに、少し設定ミスしているだけで、一発で管理者権限で入れてしまうとか。もっと単純なところでは、パスワードをちょっと想像して入力したら管理者権限で入れてしまうとか……

村島：脆弱なパスワードのTOP10に入ってくるものとか、使っている人は多いです。ルスランさんは、パスワードの脆弱性をよく見つけてきますよね（笑）。

ルスラン：最終的には、勘ですけどね（笑）。

村島：僕は、ドメイン管理者の所属グループに注意してほしいです。

川口：グループに沢山人がいると、悪い人が入っていてもわからないですからね。大事なことです。

語り切れない程の濃い内容になりましたね。今日はありがとうございました。