業界トップのペネトレーションテスター2人が語る、衝撃の“脆弱性”大公開

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

　川口洋氏は、株式会社川口設計 代表取締役として、情報セキュリティEXPO、Interop、各都道府県警のサイバーテロ対策協議会などで講演、安全なITネットワークの実現を目指してセキュリティ演習なども提供しています。2018年からはサイバー攻撃をゲーム感覚で楽しむプロジェクト「Micro Hardening」で全国ツアーを開催するなど、サイバーセキュリティに関するコミュニティ活動にも長年貢献してきた人物です。

　今回の座談会に登場するイエラエセキュリティのメンバーは、高度解析部 ペネトレーションテスト課 課長のルスラン・サイフィエフ。
そしてゲストには、三井物産セキュアディレクション株式会社より、テクニカルサービス事業本部 プロフェッショナルサービス事業部 先端技術セキュリティセンター所属の、セキュリティアナリストである小河哲之氏をお招きしました。

日本セキュリティ界の猛者と呼ばれる2人から、顧問・川口洋が衝撃のエピソードを引き出していきます。どうぞお楽しみください！。

“「レッドチーム」は「ブルーチーム」がいるからこそ存在意義がある”

川口洋（以下、川口）：小河さん、ルスランさん、まずは自己紹介をお願いします。

小河哲之（以下、小河）：三井物産セキュアディレクション（MBSD）の小河と申します。ペネトレーションテストをメインでやっています。最近は脅威ベースのペネトレ―ションテスト（TLPT）に注力しています。TLPT（Threat-Led Penetration Test）というのは金融庁が推奨しているテスト手法で、脅威ベースで行うペネトレ―ションテストです。金融庁が推奨したこともあって、最近は金融系の会社は実施したり検討していることが多いです。

TLPTでは、実際に起こる脅威として、攻撃者が誰で、どこに対して、どのような攻撃がされる可能性があるのか、といった内容を脅威分析して、その中で攻撃シナリオを作り、どれだけリスクがあるのかや、インシデントに対していかに早く気づき対応できるかなどを試す内容になっています。
（参考：「脅威ベースのペネトレーションテスト」及び「サードパーティのサイバーリスクマネジメント」に関するG7の基礎的要素の公表について）

川口：具体的には、どのようなテストをするんでしょうか？

小河：例えば「インターネットから特定の個人情報を抜き取る脅威がある」場合に、攻撃者がどういった経路で情報を抜き取っているのか、まずシナリオを考えます。ペネトレーションテストにも条件がいろいろお客さんによって違います。完全にブラックボックスな状態で、「IPだけ渡すから、テストお願いします」という場合もあります。

例えば「インターネットからWebサーバーに侵入し、さらにターゲットとする個人情報があるサーバーまで、多数のサーバーを踏み台したり、情報収集したりしながら、対象サーバーに侵入し、情報を抜き取る」というシナリオを作った場合は、実際にその攻撃シナリオが実行できるのかをテストする、という流れですね。

サイフィエフ・ルスラン（以下、ルスラン）：イエラエセキュリティ、高度解析部 ペネトレーションテスト課のルスランです。私も同じくペネトレーションテストをメインで担当しています。 具体的に言うとTLPTに近い形のシナリオベースのペネトレーションテストを行っています。また、Webアプリケーション経由で侵入する案件も多くあります。その場合、網羅的にチェックするというよりは、インジェクション系の脆弱性を見つけて侵入し、さらに内部ネットワークを調査することになります。

川口：今さらりと「侵入する」という言葉が出てきましたね（笑）。

ルスラン：（笑）

川口：お二人はもう知り合って長いということですが、何がきっかけだったのでしょうか。

小河：ペネトレーションテストや“レッド系”の情報を共有する10名ほどの勉強会を設立するタイミングで知り合って、それ以来情報交換をさせていただいています。あまり表に出ない情報なので、こういう繋がりは貴重なんです。

川口：今『レッド系』ってさらりとおっしゃいましたけど、具体的にはどういうものなんでしょう。

小河：「攻撃」側を指します。「レッドチーム」ともいいますね。

ルスラン：“レッド”側は、現実に存在する攻撃者と同じ攻撃方法などを考えた上で、実際に攻撃を行い、会社に実装されているインシデント対応プロセスの確認や対策システムの有効性などをチェックするのが役割です。一方の“ブルー”側は、“レッド”による攻撃結果によって、実装されているプロセスなどにミスがないかどうか、また強化しないといけない部分などを把握することができるんです。

「レッドチーム」に対する存在として、「ブルーチーム」という言葉があります。“ブルー”がいないと、そもそも“レッド”は存在しませんし、逆もそうです。残念ながら、日本にはインシデント対応プロセスなどのある会社や「ブルーチーム」がちゃんといる会社は多くないイメージですね。

川口：どんな組織があったら「ブルーチーム」と呼べるんですか？ SOC（Security Operation Center）やCSIRT（Computer Security Incident Response Team）があったら良いんでしょうか。

ルスラン：社内のセキュリティチーム、と言えば分かりやすいでしょうか。レッドチームによるテストや、リアルな攻撃者の攻撃に抵抗できるチームのことですね。SOCとCSIRTももちろん欠かせない部分だと思います。SOCは外部のサービスを使っているケースを見たことは数回あります。でも、その場合、外部のSOCからフィードバックされた内容や指示を、セキュリティ担当者が自分で導入できるかどうかが大事ですね。

自社でできないとなると、アウトソースしているSOCから作業する会社に結果を渡してもらって、そこから「どうしますか」と提案をしてもらうというような流れになると思いますが、なかなか難しいですね。

小河：TLPTの中では「ブルーチーム」も定義がされているんです。レッドチームの攻撃に対して、間にホワイトチームという調整役が入るものの、ブルーチームがちゃんと攻撃を検知できているかも合わせてチェックしていくことになります。

川口：「何でもいいからテストしてください」という依頼では効果が無くて、「あなたは何を恐れているんですか」と聞いていかなければいけないですね。

ルスラン：TLPTは、いわゆるレッドチームの案件を、ライトな形にしたような内容だと思います。フルスコープでやっているものを細かくして、シナリオを作ってテストするようなイメージですね。

小河：最初に対象の組織を決め、どこまでをスコープにするかを決めて、そこに対してどのような脅威があるかを分析することになっています。

“ペネトレーションテストと脆弱性診断、問題洗い出し後の役割”

川口：「脆弱性診断」と「ペネトレーションテスト」の違いを説明いただいてよろしいですか。そこの違いが、なかなか一般には理解されていない部分だと思いますので。脆弱性診断とペネトレーションテストの言葉をごっちゃにして使っていたり、予算取りのキーワードになってしまっていたりする印象があります。

小河：そうですね、「ペネトレーションテスト」自体、日本ではまだ言葉の定義がしっかりしてない状態ですよね。

「脆弱性診断」は、主にシステムの問題点を探すものだと認識しています。網羅的にシステムの問題点をチェックしていく。Webアプリケーション診断やネットワーク診断、プラットフォーム診断が多いですね。

それに対して「ペネトレーションテスト」や「レッドチーム」は、運用の問題点を洗い出すのが主な役割です。もちろんペネトレーションテストもシステムをチェックしますが、見る観点が違っていて、運用の問題点を洗うのがペネトレ―ションテストのメインの役割だと感じています。

プラットフォームやネットワークの脆弱性診断だと、バージョンが古いとか設定を間違えていることによる脆弱性だ、と明確に分かるので、それに対応していけばいいという場合も多いですが、ペネトレーションテストはもう一歩踏み込んでいかなければならないものだと思います。

川口：ルスランさんはどう考えていますか。

ルスラン：だいたい同じではありますが、私は診断で見つかった脆弱性を使って、実際に侵入出来るかどうかを試すことがペネトレーションテストだと考えています。つまり、ペネトレーションテストの目的は「インパクトを見せる」こと。ビジネスリスクがあるかどうか、会員情報が乗っ取れないか、といった情報をお客様にしっかり提示することを重要視しています。

多くのお客様は「高リスク」や「緊急リスク」と診断を受けていても、「攻撃なんてされないだろう」って思ってしまうんですよね。それを「現実に、できますよ」と見せてあげるのがペネトレ―ションテストだと思います。他にも、低リスクの脆弱性が3つ組み合わさることで、どんなビジネスリスクが発生するか、ということをチェックするのも、ペネトレーションテストが示すべき問題だと考えています。

小河：私も同じように考えています。特に、こうした“組み合わせ”による脆弱性については、運用面が大きな問題になることが多いと感じています。また一言で“運用”といっても各社ビジネスが違いますし、事業内容や働き方がバラバラなので、全てのケースに当てはまるベストな解は出しにくいですね。お客様それぞれの運用を聞きながら、毎回対策を提案していかなければいけないと感じます。

川口：脆弱性を見つけて終わるのではなくて、どう直すか、どう運用を改善するかも含めて、解決方法を提示するためには、お客様の運用について詳しくないとできない、ということですね。

小河：そうですね。テストをして「これだけ問題がありました」と報告しても、対策方法がなければ、お客様もどうしたらいいか困ってしまうので、そうならない為に私たちはどうすべきなのか、日々考えています。

もちろんこちらもお客様の業務を全てを把握しているわけではないので、報告書で対策を提案しても「運用上その対策は無理です」といわれてしまうことは多々あります。そういった時に「代替案としてこういう方法もあります、運用をこう変えることでリスクが軽減できます」といった提案をするように心がけています。

川口：そこで重要なのが「ブルーチーム」いうことですね。お二人が今、言っているようなことを意識して、報告を受ける側は「ブルーチーム」であって、報告を元に改善していかなければ、なんて意識は、なかなか無いんじゃないかな。「何のためにやってるんだろう？」っていうケースもありそうですね。

運用しているベンダーさんに「テスト結果これなので、宜しくお願いします」と丸投げしてしまうような組織だと、結果を元に継続的に改善していくような話になりにくいですね。自分の組織にITエンジニアやセキュリティエンジニア、ネットワークエンジニアを据えて、そのレベルを上げていきましょうという話にしていかないといけないですね。

「スコープを決める」ことの重要性

川口：ここまで話を聞いていて思いましたが、「スコープ」というのはお二人に染み込んでいる重要なキーワードなんですね。どこにスコープを当ててテストするか定義しないと、テスト結果をうまく活用できない。

小河：非常に重要ですね。実際の攻撃者は「Webサーバーへの攻撃」が目的なのではなく、「何か情報を盗み取りたい」とか「システムを止めたい」という目的があって、攻撃しているわけです。「システムを止めたい」場合、攻撃対象はWebサーバーだけかもしれません。でも、「何か情報を盗み取りたい」というモチベーションの時には、いろんな場所がターゲットになります。そうしたときに重要になるのが「スコープ」です。

日本の場合、システムへの影響を考えて「ここだけお願いします」という依頼も多いんです。例えば、Webサーバーをスコープにしたときに、Webのポートしかターゲットにしないというような感じです。このようにテスト対象を限定してしまうと、低リスクの問題をいくつか組み合わせることで侵入できてしまうかもしれない場合、スコープが狭すぎるせいで実際のリスクが可視化できないことがあるんです。

ルスラン：Webの診断依頼があったときに、診断対象として依頼されるのは「あるドメイン」ひとつだったとしても、探してみるとサブドメインが20個くらいあったりするんですね。そういう場合はそこまで見ないと意味がなくなってしまうので、お客様に状況を説明しに行ったりします。

川口：サブドメインから攻略すれば親ドメインまで行けるじゃないか、というケース、ありそう。

ルスラン：内部的に行ける場合もありますし、他のドメインで使われている認証情報を使って侵入できたりもします。

川口：パスワードを使いまわしてたりするケースですね。

ルスラン：最近だとAWSもよく使われているので、AWSの認証鍵を取得することができれば、AWS環境も乗っ取れる可能性があります。

川口：ちなみにルスランさんはお客さんのテスト中にAWSの鍵を盗めたことがあったりしますか。

ルスラン：……何回も（笑）。

川口：何回も！（笑）

一般人の感覚だと、「そんなに簡単に出てくるんですか？！」という感じだと思います。でもお二人からすると、探せば見つかる、という感じなんですね。

ルスラン：探せば、出てきますね（笑）。特に社内だと、開発者だけでなく、みんなあちこちに鍵を置いてたりするので、AWSの設定不備を使って特権昇格できることもあります。あとは条件次第なんですが、逆に言えば、条件を満たせば見つかることは多いですね。

川口：一般的な感覚で「ここだけテストお願いします」と依頼しても、全然スコープがあっていなくて、テスト側からすると「こっちのスコープから見れば侵入できちゃうよ」ということは沢山ありそうですね。

「低レベルと評価されている脆弱性が組み合わせることで、大きなリスクになってしまう」という相談を受けることが多いのですが、共有できる具体的な事例はありますか。

ルスラン：AWSでいえば、例えばSSRF（Server Side Request Forgery）という脆弱性があります。サーバーから他のサーバーに内部ネットワーク経由で通信できる中リスクくらいの脆弱性ではあるんですが、AWSの場合はその脆弱性が存在すると鍵が一発で取れるので、そこからパパっとAWSの環境に侵入していくことができます。脆弱性診断の結果だけ見て、「SSRFだから中リスク」と判断してしまうと、危険ですね。

外部に対してtelnetが開いていて、そこから侵入できる場合もあります。認証サービスが入っていても、空いてるポートIPを調べて、IPの持ち主はwhoisで調べて、ウェブサイトを見て会社名を利用するなどして、ちょっとだけカスタマイズすれば、管理者として入ることができてしまうことがあります。

小河：私も、WordPressの侵入を試みた時に、別のサーバーが同じアカウント名を使っていたので、同じ名前を使ってみたところ、侵入できてしまったことはありましたね。基本的に、皆さん、認証情報を使い回すことが多いので、いまは使われていない認証情報、古いアカウント情報がわかれば入れてしまったりします。

川口：命名規則が分かってしまうというようなことですか？

小河：古いパスワードが残っていたり、会社名と文字列を見たときに「こういうルールで運用しているだろうな」とパターンが分かってしまうんですね。システムアップデートを見ると、会社名+年月があって、その間に#が入っている、というような場合は、日時の数字を変えるというルールになっていると簡単に想像できます。

さきほどスコープの話をした時、サブドメインの話がありましたが、同じような状況で、本番環境は問題なくても開発環境を外部公開していて、そこを管理してないケースもありますね。管理者「admin」のパスワードが「admin」というような簡単なものが設定されているケースもあります。

本番環境の管理されているドメインは社内でExcelの台帳でユーザー名などしっかり管理されていても、開発環境は一切管理がされておらず担当者がユーザー名・パスワードを勝手に決めていたりしますね。本番環境そのものに入れなくても、開発環境に入れれば、そこを経由して本番環境も攻撃できます。

ルスラン：本番環境はWAF（Web Application Firewall）で守られているけれど、ちょっと探したらステージング環境が見つかって、そちらにはWAFがなくて、そこから侵入できたりもしますね。

川口：話を聞いてしまえば、「ああ、ありそうだね」と思いますが、使っている本人はそんなところから問題が起きるとは思っていないわけですね。

ペンテスターも焦る！脆弱性が漏らす 「衝撃的な内容」

川口：お二人ともこれまで数多の経験の中で、同じようなケースを見てきたわけですね。ちなみに、今まで侵入して見つけた中で衝撃的なものはありましたか？

小河：詳しくはお話できないですが、あまりにもセンシティブな情報が置いてあったのを見つけてしまったことがあって「これは今すぐ消してください」と急いでお願いしたことはありますね。「認証があるから守られている」と担当者の方は思いがちなんですが、裏口までチェックできていないケースが多くて、侵入できてしまうケースは多いんです。

川口：まるで「3匹の子豚」みたいですね。木の家、藁の家を建てて大丈夫だと思ってたけど、狼が現れたら家壊されちゃいますよ、ちゃんとレンガで作りましょうよ、ということですね。

小河：1年経ったら裏のレンガが崩れかかっていて、そこからちょっとずつ崩していたら入れちゃった、ということもあります。定期的にチェックした方が良いと感じますね。

ルスラン：衝撃的なことは、いろいろ、あり過ぎるほどありましたね（笑）。私はプライベートでBug Bounty（バグ報奨金プログラム）をやっているんですが、ある会社全員の個人情報がパーッと出てきてしまったことがあります。

まずサブドメインを探して、認証情報を見つけます。認証情報を特定のIPで探したところ、突破できました。更に認証画面が出てきて、ここに何を入れればいいか探していたところ、その会社が提供してるAPIがGitHubに公開してあったんですね。「ログインするならこのパスワードを使え」とあったので、そこに書いてあったパスワードを使ったら侵入できてしまいました。

特定のIPアドレスからしか入れないことになっていることで、「守られている」という考えだったんだと思います。けれど、いくつかの脆弱性を組み合わせれば入れてしまいます。制限方法によっては、そもそも脆弱性があるままだったりしますしね。

川口：倫理観を持ったお二人がやっているから大丈夫ですが、悪意のある人に見られたら大変ですね。そんな簡単に個人情報が見られてしまうというのは、一般の方にとっては衝撃だと思います。

求められる「事前手順化」と「実践的なテスト」の間に横たわる相互理解のハードル

川口：未公開の脆弱性を見つけたことはありますか？

ルスラン：日本製の端末管理ソフトのようなシステムで、見つけたことがあります。悪用すると特権昇格ができてしまう脆弱性でした。

川口：それは厄介ですね。でも、導入している製品に未発表・未発見の脆弱性があったら、導入している会社さんやユーザーさんはどうしようもないですよね。ソフトウェアの開発元に「直してください」とお願いするしかない。

ルスラン：その問題の場合は、グループポリシーで対応することができました。でもソフトに依存する場合はソフトの開発元が対応してくれないとどうにもならないですね。

川口：小河さんはWindowsDefenderをかいくぐるのに一生懸命と聞いてますが。

小河：どの企業もセキュリティ製品を入れて対策するのが当然なんですが、テストする時にそこがネックになると困るので、そういったセキュリティ製品をバイパスできるように日々研究しています（笑）。日々変わっていくものですしね。

ルスラン：シナリオにも依るので、セキュリティ対策ソフトが無い条件でやる場合もあります。でも最終的には、テストをする個人の経験や知識に依存する場合が多いですね。

小河：そこに依存しちゃいますよね。

川口：汎用的な知識を持った、学校を出たばかりの人ではなくて、数多の経験を積んできた猛者がペネトレーションテストやらないと、全然意味が無いわけですね。そういう「出来る」人間が、日々あの手この手で研究しているということが重要ですね。そんなスペシャリスト、日本に100人もいなそうな気がします。

小河：いて欲しいですけどね（笑）。ペネトレーションテストは決められた手順で行うものではないので、おっしゃるとおり、経験を積みながら、日々勉強しながらやっていかないと難しいですね。

ルスラン：ペネトレーションテストをやっている人は、「これまでに見たことがない状況」になった時にどうするかが大事です。日々勉強していて「こんな脆弱性もありうる」と試してみるか、「何もなさそうから、何もないだろう」とそこで終わっちゃうかで結果が違ってきてしまいます。

川口：お二人は「絶対、脆弱性がある」と思ってシステムの脆弱性を探っていることですよね。そういうマインド的なものもあるんですね。手順書があって、「この手順通りにやってください」で済む話では無いんですね。

「手順書が無い」中で脆弱性を見つけていくのがペネトレーションテストの本質である一方で、ハードウェアを作るような製造業のお客さんだと、「テストを手順化してください」というケースも多いと思います。

製造業だと手順を標準化して品質を向上させる、製造ラインのプロセスにするのが仕事だったりしますよね。全ての機器がコネクテッドな形でインターネットに繋がるようになってきている今、そういう人たちとビジネスすることも多いでしょう。セキュリティ業界トップクラスの人が経験を駆使してテストするのに、「事前に手順書作ってくれ」と言われて、困ることもあるんじゃないでしょうか。

小河：そこは日々説明して、理解頂くよう努力するしかないですね。

ある組織の診断を依頼された時「診断手順を全て明確にして、その手順をベンダーに説明して問題ないことを確認してからテストしてください」と言われたことがあります。見たことがないシステムで、何が動いているかも分からない状態だったので、事前に全て手順化することはできないということを説明しました。

最近はそういうものだと段々理解いただいて、「こういう観点で行います。例えば、Webサーバーのポートスキャンして、ウェブサービスを見て、ウェブ上の問題点がないか確認して...」といった手順はお伝えしていますね。「具体的に何のデータを送信する」とか「どういう認証パターンをテストする」ということを言わなくても良いようには、なってきていると思います。

川口：日本に100人位しかいないトップクラスの人達がペネトレーションテストしているとは思ってなくて、何かマニュアルに従って品質管理のプロセスの一部として手順通りにやっているんでしょう、と思われているのかもしれませんね。それだったら、「手順を開示してください」という気持ちは分かります。

もしかしたら通り一辺倒のテストをして、「ペネトレーションテスト」とはとても呼べないものをペネトレーションテストとして実行しているケースもあるかもしれませんよね。スキャンツールを回してるだけとか。トップレベルの人がテストしないと発見できない問題や改善点もある、という認識が無いのかもしれません。

小河：それは本当にもったいないですね。お金を払う側ももったいないですし、我々としても、本来のペネトレーションテストのあるべき姿とずれるのは良くないと思っています。

テストを依頼された時は、目的を確認することが多いです。何を目的としているのか。Webアプリケーションの問題点を見つけたいのか、それとも侵入されたら困るのかなどです。テストの依頼に至った経緯まで遡ってヒアリングしていくことで「こういうテストシナリオや、こういうサービスのほうがいいんじゃないか」という適切な提案ができるんですね。

ルスラン：テストの目的を合意することは大事ですね。そうでないと、最終的に報告書を出したときに「これは期待していない結果だった」となってしまう危険性があります。

川口：ペネトレーションテストをどういう期待値で行うか、受けた後にどう改善していくのかを考えていないと駄目ですよね。「脆弱性が無い、100点満点がほしい」というお客さまにはペネトレーションテストは難しいですね。何か問題は発見されるのだから、「改善するプロセス」として頼んでもらうのが良さそうですね。

ルスラン：それが一番いいですね。

外部からの侵入対策は分厚いが、内側は“楽園”の日本企業

川口：こういうシステム、こういう運用は侵入しやすい、危ない、というのを教えていただけますか。この座談会記事を読んでいる皆さんに気をつけて頂きたいことは、何でしょう。

ルスラン：最近はクラウド経由の侵入が多いですね。昔はWebサイトに脆弱性があったとしても、場合によってそのサーバーの情報だけで被害が済んだんですが、最近だとAWS、Azureで認証鍵が取れるので、それを使ってクラウドにある他の端末にも行けて、それで大変なことになってしまいます。クラウドは便利だけど、リスクもあるので、鍵の制限をちゃんとしてほしいです。

あとは、日本の場合、私の見てきた経験だと、外部はファイアウォールなどで結構守られてる印象があります。でも、いったん中に入ると攻撃者にとっては楽園というか……

川口：楽園（笑）。

小河：それは非常に感じますね。

川口：「中に入る」というのは、標的型メールを開いてしまった後、というような状況でしょうか。

ルスラン：それもありますが、物理的に攻撃者が組織内部に入ってLANケーブルを刺しちゃうとか、そもそも内部の人が攻撃者の場合もありえます。このような場合は社内のネットワークに繋がっている状態なので、いろいろ簡単に出来ちゃうんですね。取引先の営業マンが攻撃者だったり、PCを盗まれた場合など、いろいろなケースが考えられます。

川口：インターネット経由はそれなりに守られていても、一度中に入ってしまうと驚くほど守りが弱いわけですね。小河さんも強く頷いてますね（笑）。

小河：仰るとおりなんです。ファイアウォールなど外からの入口は、長年言われていることもありちゃんと対策されているんですが、内部はやりたい放題のケースが多いです。

ネットワーク担当の方が「ここはセグメントが分かれてるから大丈夫」と思っていたら、実際には分かれておらず、制限されていなかったりすることもあります。物理的な侵入や内部犯行を想定すると、簡単に権限昇格できたりするケースは非常に多いですね。

ルスラン：内部の話になると、運用の問題が多く出てきますね。一般のユーザなのに管理者権限を使っていたり、端末ごとに同じパスワードが使われていたりといったケースが目立ちます。

小河：大企業になると、各クライアントPCはコピーして渡していくので、同じキッティングルールに則った設定になっていることが多いんです。作成時のアカウントがそのまま残っていると、全部パスワードも同じなので、1台侵入されると全部ダメになってしまう。

ペネトレーションテストのシナリオにもよるんですが、「会社のPCが1台手に入ったら」という想定で、企業から1台提供してもらい、そこからどこまで入れるかテストすることがあります。それで、提供されたPCに入ってみるとデスクトップの特定のファイル内にサーバーのパスワードが残存しており、そこから入って権限昇格ができてしまうといったようなことがありますね。

川口：よくあるケースですね。事故が起こった組織の事故調査報告書にも、システム運用事業者のデスクトップに「パスワード管理台帳」が置いてあった、と書いてありました。

ルスラン：マニュアルにパスワードが書いてあったり、プロセスを自動化するためスクリプトファイルに認証情報が書いてあったりもしますよね。また、認証情報のあるスクリプトファイルを配布する時に、ドメインコントローラーの特定のフォルダに入るだけで見れたりとか。

あとは例えば、ハードコーディングされたパスワードをセキュアだと考えている組織もあると思います。私が見たケースだと、自作で作ったツールに埋め込んでいて、サポートの人や担当者の人にPCを渡すときに、パスワードを渡す必要がなくなるので安全だと考えている場合がありました。でもそれって、解析できる人が手に入れたら、パスワードは見えちゃいますよね。

川口：一分くらいで？

ルスラン：一分は厳しいですけど...（笑）

川口：コーヒー飲んでるくらいの時間で取れちゃうわけですね。

小河：認証情報をどう管理するかは、非常に難しい問題です。会社の運用上、それを是正するのが厳しかったり、システム上難しかったりするときに、そのリスクをどう軽減させるか。都度考えるのが大変ですね。私自身もベストな提案が常に出来ているかは分からないですが、運用している人とディスカッションしながら、毎回勉強しながら知識をアップデートしていかないと難しいですね。

「特定の認証製品を導入しているので、ここのリスクは軽減できているが、他のリスクはどうなんだろう」といった感じで、製品の知識もアップデートしていく必要があります。セキュアな状態で「運用し続ける」ことが一番重要だと思います。一瞬ではなく常にセキュアであり続ける、常にチェックする体制を整えることが大事ですね。組織が変わるだけで運用が変わって、そこで問題が出たりもしますから。

川口：退職者アカウントでログインできたりするケースもあるんじゃないですか。

小河：古い設定が残ってるケースは、問題になることも多いですね。最近のアカウントはパスワードポリシーを変えてセキュアな設定になっていても、古いアカウントが以前の緩いポリシーで、例えば数字6桁でログインできたりというケースもあり    ます。「無効化してるので大丈夫だろう」と思っていても、何か間違って有効にしてしまったら終わりです。なので、可能であれば使っていない古いアカウントは全て削除してくださいとお願いしています。

「お二人とも、セキュリティ企業で働いていて下さいね（笑）」

川口：最近お2人が気になっている技術や製品はありますか。

ルスラン：日本のいろんな製品の脆弱性を試してみたいと思っています。海外の製品は海外の人たちが大体見てるんですが、日本の製品はまだそこまで見られていないので。

小河：私は最近、Windows Defenderのようなセキュリティ製品をいかにバイパスするかを考えていて、Mimikatz（ミミカッツ）のような攻撃ツールを自作したりしています。（参考：攻撃的セキュリティツール、Mimikatzとは（前））

川口：一般的な攻撃ツールでは対策されてしまうから、小河オリジナルツールを作っているということですね（笑）。

小河：はい、Mimikatzでは特徴点があるのでDefender等に拾われてしまう攻撃でも、自分でゼロから作れば、公開しなければ特徴点はバレませんので、そうすれば大体バイパスが出来ます。

川口：普通の人からすると、「そんなツール、ゼロから作れるんですか！？」って感じですが……。

小河：頑張ってやってます。Mimikatzのように、既に実現してる例があるので、何とかなるだろうと。

ルスラン：簡単なものだと変数の名前変えたりからですね。ある機能が不要なので消してみる。そうするとコンパイルしたハッシュが変わることで実行できるパターンも出てきたり。他の言語に書き換えたり。

小河：変数名を変えるのは非常に単純なんですが、Defenderだと最近は大体ブロックしますね。

ルスラン：Defenderも結局人が作るモノなので、同じ方法でバイパスも出来てしまうんですよね。

川口：世界で何兆円も使って開発しているソフトのセキュリティに一人で立ち向かっているわけですね。絶対こいつら倒してやる、と……。二人とも、悪い人たちに連れ去られないことを祈っています！　セキュリティ企業で働き続けてくださいね！（笑）

そんなお二人に、お互い「実は、これを聞いてみたかった」ということがあったら、この機会に質問をしてみてもらえますか？

小河：聞きたいこととなると、具体的な攻撃手法になってしまうんですよね（笑）。ルスランさんは、リバースとかプロセスのダンプや解析まで、その場でやったりしますか。権限が取れてしまったときとか。

ルスラン：必要に応じてやっていますね。

小河：それは自分の感覚で？

ルスラン：怪しいプロセスが実行されていれば、これは自作のプログラムだろう、じゃあ、exeを取ってきて解析してみようか、とか。必要によってですね。

小河：exeの場合だとバイナリーとかアセンブラとかそこまで見ます？ ペネトレーションテストの期間や内容にもよると思いますが。

ルスラン：自分の能力の範囲でやってみる感じですね（笑）。

小河：例えば、認証情報をハードコードしたプログラムをexeにした場合に、文字列として残ってるものがあったりするじゃないですか。そのexe自体を侵入に悪用されるケースがあったりしますが、解析をしない限り、パスワードが分かって初めて分かる脆弱性ですよね。いきなりアセンブラのチェックまでするかは、難しいですよね。

ルスラン：具体的にあった事例でいうと、exeは見つけられたんですが、Go言語で書かれていて解析が難しかったんです。その時は何をやってるか見て、トレースできるものに入れて、最終的にハードコーディングされている箇所のファンクションで、PowerShellに2つのパラメータを渡しているのがわかりました。1つめはアカウント、2つめはパスワードだった、みたいな感じですね。ものによってやり方は変わってくるところです。

川口：すごい（笑）。実務でやってる方ならではの話ですね。ルスランさんは小河さんに聞いてみたいことはありますか。

ルスラン：標的型メール攻撃の経験はありますか？

小河：弊社でもやっていますが、あまりメインではやらないですね。標的型メールは日本では開く方が「悪」。開いてしまった人が血祭りにあげられるような状態ですよね。

「最近こういうメールが来るよ」という啓蒙としてはやるべきだと思いますが、何人開いた、誰が開いたというところは重要じゃないと思います。誰か必ず開いてしまうものなので、開いてしまっても検知が出来るとか、攻撃を局所化できる組織にするとか、そういうセキュリティ対策ができていることの方が重要だと思います。

ルスラン：私も、誰がいつ開いたという話よりも、開いてしまって、実行して、シェルを取られたとか、そういう情報を知りたいですね。最近だと入口がしっかりしていて、フィッシングメールで対応できない場合に製品を突破できないか、という案件もたまにあったりします。

小河：製品をいかにバイパスするかの話になってきますね。攻撃コードを1byte変えてとか、製品を素通りさせるかみたいな話になると、特定の製品の評価になってしまう気もしています。

ルスラン：何も分からないブラックボックスでのテストは結構楽しいですけどね（笑）。

ペネトレーションテスターになりたい貴方に、まず経験して欲しいこと

川口：ペネトレーションテスターになりたい人とたまに会うんですが、何かおススメの勉強や経験などあったりしますか。

ルスラン：システムの開発経験を得てきてほしいですね。自分はそこが足りてないと思っていて、プログラミングができればもっといろいろ出来ると思います。開発系の企業に1度入ってもいいし、自分で勉強してもいいと思います。

小河：その他にあるとしたら、好きな技術を突き詰めることですね。強みを作って、次の分野に行って、を繰り返していくと、すごいペンテスターになっていると思います。自分も全ての技術に精通しているわけじゃなくて、そういう人が集まってテストをしていくので。

ルスラン：レッドチームのペンテスターの中でも、それぞれ役割があります。ある人はリバースエンジニアリングが出来る、ある人はネットワークが強い、といったように。自分の強みを探すのが重要だと思いますね。

川口：だからレッド“チーム”なんですね。

ルスラン：1人でやるには時間と知識が足りないですね。

小河：脆弱性も、コードが公開されているからそのまま攻撃すればいい、というわけではないんです。例えば攻撃した結果サーバが落ちてしまったら、意味がないわけですよ。いかに落ちないように検証するか。経験や知識を皆で共有してやっていかないと良いサービスにならないと思います。

川口：そういう人がいるって大事ですよね。イエラエにしてもMBSDにしても、そういうことが出来る人間が何人かいるから面白いし、お互い高めあうことができるんですよね。そこは大きなポイントな気もしますね。

最後に、お二人に今後の野望を一言ずつでいいのでお聞きしたいです。今後していきたいことや、目標をお願いします。

ルスラン：私はレッドチームやTLPTをやってみたいなと思っています。ペンテストをやっていくと常に進化していかないといけないので、次はレッドチームのような方向かなと思っています。

小河：自分もそうですね。あとは、組織のセキュリティレベルをいかに上げていけるかに注力していきたいですね。

川口：本日はありがとうございました。