10月13日、NICT(情報通信研究機構)が「A2B攻撃」という攻撃への対策を公表した、というニュースを読みました。10月に入ってから大きな情報漏えいの報道が続いていたので、気になって開いた記事です。
ただ、読み進めると「SSRF」「IDOR」など、見慣れない英字の略語が次々に出てきます。そこで、システムに詳しくない方にも伝わるように、身近な例えを使って整理し直してみました。
なお、NICTの一次資料はまだ見つけられていません。以下はニュース記事をもとにした私の理解です。
ニュースを一言でまとめると
「スマホアプリを分解して裏側の仕組みを調べ、その弱点を突いて個人情報を盗む手口が、相次ぐ情報漏えいの原因の一つになっている」という内容です。
- 攻撃者は、公開されているAndroidアプリを入手して中身を調べます。
- アプリの裏側にあるサーバー(データの保管庫)の弱点を探します。
- 見つけた弱点を突いて、情報を盗み出します。
「Androidアプリの問題」に見えますが、読み解くと、本当の問題はアプリではなく裏側のサーバーの守りが甘いことでした。
「A2B」とは?お店で例えると
A2Bは「App to Backend(アプリから裏側へ)」の略です。ここでお店の例えを使います。
- アプリは、お店の「接客カウンター」です。お客さんはここで注文します。
- サーバー(バックエンド)は、お店の「バックヤード」です。会員名簿や注文履歴がしまってあります。
- APIは、カウンターとバックヤードをつなぐ「注文伝票のルール」です。
普段のお客さんは、カウンターを通してしか注文しません。ところが攻撃者は、カウンターの仕組みを調べ上げて、伝票のルールを真似て、バックヤードに直接注文を投げ込みます。これがA2B攻撃のイメージです。
アプリの中身は、実は見られる
アプリを分解して中身を調べることは、「リバースエンジニアリング」と呼ばれます。Androidアプリは専用のツールを使うと、通信先のサーバーや、どんな伝票(API)の出し方があるかが、ある程度読み取れてしまいます。
つまり、アプリの中に書いてあることは、攻撃者にも見えていると考える必要があります。
記事には、AIの活用で解析や弱点探しが効率化されている、という指摘もありました。手間が減れば、狙われるアプリが増えるのは自然な流れだと感じます。
狙われた4つの弱点
記事では、攻撃の対象になった弱点が4つ挙げられていました。専門用語ですが、中身は意外と単純なので、例えで説明します。
① IDOR:番号を書き換えると他人のデータが見える
いちばん分かりやすく、私がいちばん引っかかったのがこれです。
たとえば、自分の注文履歴が次のアドレスで表示されるとします。
/api/orders/1001 ← 自分の注文この番号を「1002」に書き換えるだけで、他人の注文が見えてしまう。これがIDORです。原因は、サーバーが「この人は本当にこのデータの持ち主か?」を確認していないことです。
例えるなら、ロッカーの鍵を確認せず、番号を言うだけで荷物を渡してしまう受付のようなものです。
アプリの画面では、自分の分しか表示されないようになっているかもしれません。しかし攻撃者は、画面を通さずにサーバーへ直接アクセスします。画面での制限だけでは防げないというのが、今回のニュースの核心だと思います。
② SQLインジェクション:入力欄に「悪い命令」を紛れ込ませる
データベース(情報の倉庫)には、専用の言葉で命令を出します。その命令の中に、入力欄から悪い命令の一部を紛れ込ませて、本来見せてはいけない情報を引き出す手口です。
例えるなら、「山田さんの書類を持ってきて」という依頼票に、こっそり「全員分も」と書き足されてしまうようなものです。古くから知られている弱点ですが、今回も挙がっているので、まだ対策が不十分な場所が残っているのだと思います。
③ SSRF:サーバーをだまして、危ない場所へ使いに行かせる
サーバーには、外部の人は入れない「社内の部屋」にもアクセスできる権限があります。その権限を悪用し、サーバー自身に、外からは届かない場所の情報を取りに行かせるのがSSRFです。
例えるなら、社員証を持つ人をだまして、立入禁止の部屋から書類を持ち出させるようなものです。
AWS(アマゾンのクラウドサービス)を使っている場合、サーバーの鍵のような情報がこの経路で盗まれるおそれがあります。対策として「IMDSv2」という設定を有効にする方法があり、自分の関わる環境でも確認しておきたいと思いました。
④ RCE:サーバーを乗っ取られる
遠隔から、相手のサーバーで好きなプログラムを動かせてしまう状態です。4つの中で、被害はもっとも大きいと思います。
例えるなら、お店のバックヤードの合鍵を作られて、自由に出入りされる状態です。情報を盗むことも、書き換えることもできてしまいます。
公表された対策
対策は「暫定対策」と「恒久対策」に分かれていました。
- 暫定対策は、応急処置です。被害を広げないために、すぐできることをやります。
- 恒久対策は、根本治療です。原因そのものを取り除きます。
暫定対策(応急処置)
アプリを公開している事業者に向けて、次のことが呼びかけられています。
- すでに侵入されていないかを確認する
- 弱点がないかを点検する
- 国外などの不要なアクセス元からの通信を、一時的に制限する
ただし、通信制限は海外の正規の利用者や連携先まで止めてしまうおそれがあります。入れる前に影響範囲を確認することが大切だと感じました。
恒久対策(根本治療)
恒久対策は、次の2つです。
- サーバー側で認証・認可を行う
- サーバー側で入力内容をチェックする
ここで「認証」と「認可」の違いを押さえておきます。似た言葉ですが、確認していることが違います。
| 言葉 | 確認していること | 例え |
|---|---|---|
| 認証 | あなたは誰か | 受付で身分証を見せて、本人だと確認する |
| 認可 | あなたはそれをしてよいか | 本人だと分かった上で、そのロッカーの持ち主かを確認する |
先ほどのIDORは、認証はしているのに、認可をしていない状態です。ログインはさせているのに、「そのデータを見てよい人か」を確かめていない、ということです。
「入力内容のチェック」は、送られてきた内容が想定どおりかを確かめることです。数字のはずの欄に変な文字が入っていないか、許可していない宛先ではないか、といった確認です。SQLインジェクションやSSRFは、ここが甘いと起きやすくなります。
いちばん大事な考え方:「アプリは信用しない」
記事の最後に、NICTの見解として、次の点が書かれていました。
- 攻撃者はアプリを通さず、サーバーに直接アクセスできる
- そのため、アプリ側の制限に頼らず、サーバー側で守る必要がある
- この攻撃はAndroidに限らず、iPhoneアプリやWebサービスでも起こり得る
つまり、アプリは「お店の中」ではなく、攻撃者の手元にもあると考える必要がある、ということです。ボタンを隠しても、入力欄でチェックしても、裏口から直接アクセスされたら意味がありません。
「自分たちで作って配ったアプリだから大丈夫」という感覚は、つい生まれやすいのかもしれません。私自身、アプリからしか呼ばれない前提で作ったものを、どこまで疑えていたかは怪しいと感じました。
おわりに
最初はAndroidアプリの話だと思って読み始めましたが、中身は**「裏側のサーバーを、誰が来ても守れるようにしておこう」という基本の話**でした。4つの弱点も、どれも以前から知られているものです。それが今あらためて情報漏えいの原因に挙がっていることに、少し考えさせられました。
次は、自分が関わっているサービスで、「この人はこのデータを見てよいか」という確認がサーバー側にあるかを、一覧にして点検してみたいと思います。NICTの一次資料が見つかれば、追記する予定です。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
