国立研究開発法人情報通信研究機構(NICT)は13日、国内で相次ぐ情報漏えい事案の原因の一つとして、公開アプリを悪用した「A2B攻撃」を特定したと発表。3種類の推奨対策をまとめて公表した。
日本国内では10月に入ってから、個人情報などの大量漏えい事件が相次いでいる。
多くの事件ではまだ攻撃手法には不明な点も多いものの、NICTの脅威情報分析チーム「LETTICE」の調査・分析では、原因の一つとして、公開Androidアプリの解析結果を悪用し、アプリの接続先サーバーの仕様に合わせた攻撃を行なう「A2B攻撃(App-to-Backend Attack)」を特定した。
引用：https://news.yahoo.co.jp/articles/575a7a706b31609592341e223017f640ddc7460f
─ YODOQの見方───────────────────────────
YODOQの見方として、今回のA2B攻撃の仕組み・狙われる主な脆弱性・NICTの推奨対策をまとめてみました。
1. A2B攻撃の仕組み
(1)攻撃者がGoogle Playなどで公開されているAndroidアプリを入手する
(2)アプリを解析（逆コンパイルなど）し、接続先のサーバー、APIの仕様、鍵などを調べる
(3)調べた情報をもとに、そのサーバーに合わせた攻撃をバックエンドへ直接仕掛ける
(4)サーバーに認証・認可や入力値検証の不備があれば、個人情報が漏えいする
2. 狙われる主な脆弱性
(1)SSRF（Server-Side Request Forgery）
外部からのリクエストによって、バックエンドサーバに本来意図していない通信を行わせる脆弱性で、外部から直接アクセスできない内部システムやクラウド環境のメタデータなどにアクセスされ、機密情報が取得される可能性がある。
(2)RCE（Remote Code Execution）
外部からのリクエストによって、バックエンドサーバ上で不正なコマンドやプログラムを実行できる脆弱性で、サーバ内の情報の窃取、データの改ざん、不正なプログラムの実行など、深刻な被害につながる可能性がある。
(3)SQL インジェクション
APIなどへの入力を通じて、バックエンドのデータベースに対する不正SQL処理を実行させる脆弱性で、データベースに保存されている個人情報などが不正に取得されたり、認証が回避されたりする可能性がある。
(4)IDOR（Insecure Direct Object Reference）またはBOLA（Broken Object LevelAuthorization：オブジェクト単位の認可不備）
API などで利用者 ID やデータ ID といった識別子を指定する際に、適切なアクセス権限の確認が行われていないことで発生する脆弱性で、他の利用者の氏名、メールアドレス、その他の個人情報などが不正に取得される可能性がある。また、識別子が容易に推測・列挙できる場合には、大量の情報漏洩につながるおそれがある。
3. NICTの推奨対策
(1)侵害の確認
公開APIやサーバを洗い出し、アクセスログなどから不審なアクセスや情報の不正取得がないか確認してください。
(2)脆弱性の点検
APIの認可不備（IDOR/BOLA）、SSRF、RCE、SQLインジェクションなどの脆弱性や設定不備を重点的に点検してください。
(3)暫定的な緩和策
不要なAPIの停止、アクセス制限、監視の強化、認証情報の無効化・再発行など、必要な対策を実施してください。
直近で報道されている主な事案としては、ローソン、第一興商、スカイチケット、バイトル、ブックオフ、タイムズなど免許証などの本人確認書類を含む事案もあり、金融庁が本人確認をICチップ読取に一本化する時期の前倒しを要請する事態となっている。
今、こういった被害が急増している背景にはAIによるアプリ解析の効率化が上げられる。
今後、我々としても意識しないといけないのは、バックエンド側の設計として、クライアントは信用しない。アプリであろうが、Web画面であろうがクライアント側でのチェックは利便性を高める手段でしかなく、認可チェックはバックエンドサーバ側で実施することを徹底し、不要なAPIやテスト用APIなどいらなくなったものは非公開や削除しておく。
WAFやAPIゲートウェイの導入、定期的なログ解析やバックエンド側のAPIエンドポイントをAIで解析させ、脆弱性対策をチェックし、効率的に脆弱性を潰していくことが必要である。
