エーアイセキュリティラボ 開発本部の檜垣です。
脆弱性診断の現場では、さまざまなシステムの制約に対処しながら診断作業を進める必要があります。特に、二要素認証が実装されているシステムは、セキュリティの観点からすると非常に有効な機能なのですが、脆弱性診断の観点からすると、ツールによる自動診断を阻害する要因の一つとなります。
今回は、あるオンサイト診断の現場で二要素認証の壁にぶつかり、最終的に「自分たちが診断ツールの一部になる」ことで、どのように診断を乗り切ったのかをお伝えできればと思います。
● オンサイト診断で直面した問題
診断員2名で、お客様先でのオンサイト診断を実施しました。これは、インターネットに公開されていないシステムに対し、お客様の環境内で直接アクセスして行う診断形態です。
診断対象のWebアプリは、ログインすると事前に登録したメールアドレスに6桁のOTP（ワンタイムパスワード）が届き、その値を次画面で入力することでログイン後のページに遷移できるという仕様になっていました。
OTPのメールはインターネット経由で送信されますが、お客様環境の制約上、診断PC側のメールアプリで受信することができず、二要素認証時はスマホのメールアプリを開き、受信したOTPを見て、入力しなければなりませんでした。
そのため、このような制限下で二要素認証を診断するとなると、スマホに送信されるOTPの値を技術的に診断PCに共有することができず、自動診断で対応することができません。
このようなケースの場合、通常は優先度の高い範囲のみに絞って診断対応する手動診断に切り替えるのですが、今回ペアを組んだ診断員には手動診断の実務経験がなく、その場で教えながら進めるという時間もありませんでした。私が手動診断を担当するとしても、作業分担がうまくできずに、診断期間内に診断を完了させることが難しくなる可能性は高そうです。さらにはお客様側のシステム担当者の方も別拠点から来られており、診断期間を延長するのも避けたい状況でした。
● 解決策：診断ツールの一部になる
このままでは診断が期間内に完了しない可能性があります。そこで、私たちは窮地を脱するため、文字通り「診断ツールの一部になる」という苦渋の決断を下しました。つまり、自動診断として対応しながらも、OTPの手動入力をひたすら繰り返すという、時間と労力を要する作戦です。
● [前提] 診断環境の制限
・インターネットから隔離されている
・登録するメールアドレスは自社の診断用メールアドレス
・OTPのメールはお客様の環境の制限上、診断PCで受信することができず、閲覧できるのは私の社用スマホのメールアプリのみ
● 作成したツール
作成したのは軽量のWebアプリで、非常に簡単な作りのものです。(以降、otp.pyと呼びます。)
● 仕様の説明
使用している診断ツールがOWASP ZAPやBurp Suiteのようにパラメータを引き継ぐ機能があり、OTP送信する通信とOTPを使用する通信の間に、otp.pyにアクセスするようにセットしました。
診断ツールに組み込むHTTP通信の流れは以下の通りです。
① OTPをメールで送信するエンドポイントへアクセスします。その後、事前に登録したメールアドレスにOTPが送信されます。
② otp.pyへ通信するために、http://localhost:5000へアクセスします。
③ otp.pyを起動しているコマンドプロンプト上に「OTP>>」と表示され、入力待ち状態になります。（この間は②のレスポンスは応答されずに待機となります。）
④ ①で受信しているメールを開きOTPを確認します。
⑤ ③で入力待ちになっているコマンドプロンプトに④のOTPを入力すると、②で待機しているレスポンスにOTPの値を記載して返します。
⑥ OTPが必要となるエンドポイントに⑤で受け取ったOTPを送信します。
otp.py
from flask import Flask, Response
import logging
app = Flask(__name__)
app.logger.setLevel(logging.ERROR)
log = logging.getLogger('werkzeug')
log.setLevel(logging.ERROR)
@app.route('/')
def input_number():
user_input = input("OTP >> ")
while not (user_input.isdigit() and len(user_input) == 6) and user_input != "exit":
print("6桁の数字を入力してください\n")
user_input = input("OTP >> ")
return Response(user_input, status=200)
if name == '__main__':
app.run(debug=False)
● 実行の様子
桁数や数値以外の値を入れた場合は、何度も繰り返し入力することができます。
6桁の数値での打ち間違いは対応できないので、一度診断ツールを止める必要があります。
● レスポンスの様子
入力された値を返すだけとなります。この値を後続のHTTPリクエストのOTPパラメータに引き継ぎます。（これが⑤のレスポンスとなります。）
● 実際に使ってみて
メリット
・この仕組みを取り入れると誰でも診断が可能になる
・実質的に自動診断の形を取れるため、診断の品質は診断ツール側で一定の担保ができる
デメリット
・とにかく時間がかかる
・パラメータが少ない場合でも4時間弱かかった
・実施中は常にメールアプリを更新し、新規メールを開きOTPを入力し続けないといけない（体力と精神力が必要）
・入力ミスが許されない
・入力タイミングなどを間違えるとOTPが重複する可能性がある
・時々スキャン結果を確認しながら慎重に進める必要がある
・OTPが重複したり入力ミスしたりすると、やり直し。失敗する度に余計な時間がかかってしまう
● 振り返りとその後
このツールが、難局を乗り切るための鍵となりました。本当に作って良かったです。
時間と労力はかかりますが、診断メンバーとバランスよく作業分担ができ、私は自動診断以外の診断タスクを片付けることができました。私も一部otp.pyで作業をしましたが、かなり楽に診断を進められていると実感しました。otp.py はその後もブラッシュアップをしていき、さまざまな診断案件で活躍しました。
（診断対象のWebアプリごとに微調整が必要ですが、状況によってはこの手法が一番効率的な時もあります。とはいえ、人によっては向き不向きがある作業なので、実践する際は小休憩を挟みつつやってください。）
● 最後に
脆弱性診断の現場では、二要素認証のような強固なセキュリティ機能が自動診断の障壁となることがあります。しかし、今回の事例のように、コーディングスキルを活かして自作ツールを開発することで、業務効率化や困難な問題に対する柔軟な対応が可能となります。この経験は、コードを書くことが少ない診断現場においても、技術的な選択肢を広げることの重要性を実感させるものでした。
このように診断の現場では「手動でしかできない」ものも存在します。一方で、自動診断ツールも進化しており、様々な認証方式に対応しているケースも多いです。
ここからは宣伝になりますが、クラウドサービスとして提供しているAeyeScanは、二要素認証やリスクベース認証によるセキュアなログイン環境を備えています。また、生成AIによる多言語フォームへの対応や、カスタムヘッダ付与による認証後画面の巡回など、高度な自動スキャン性能を実現しています。私のように苦労した経験を持つ診断員の方にも是非さわってみて欲しいです。
