遭遇する可能性のあるアプリのほとんどはリモートエンドポイントに接続します。動的解析 (トラフィックのキャプチャと解析など) を実行する前であっても、アプリケーションが通信すると思われるドメインを列挙することで、初期入力やエントリポイントを取得できます。
通常、これらのドメインはアプリケーションのバイナリ内に文字列として存在します。これを行う方法の一つは、Apkleaks や MobSF などの自動化ツールを使用することです。
あるいは、正規表現を使用してドメイン名を grep できます。これを行うには、アプリバイナリを直接対象とするか、リバースエンジニアして逆アセンブルまたは逆コンパイルしたコードを対象にします。後者のオプションには明確な利点があります。それは コンテキスト を提供できることです。各ドメインがどのようなコンテキストで使用されているか (クラスとメソッドなど) がわかる可能性があるためです。
ここから、この情報を使用して、後の解析時に役立つ可能性のある洞察を多く導き出すことができます。たとえば、ドメインをピン留めされた証明書や Network Security Configuration ファイルと照合したり、ドメイン名のさらなる調査を実行してターゲット環境についてさらに詳しく把握します。アプリケーションを評価する際は、Network Security Configuration ファイルをチェックすることが重要です。これは (安全性の低い) デバッグ構成が誤って最終リリースビルドにプッシュされることが多いためです。
安全な接続の実装と検証は複雑なプロセスになる可能性があり、考慮すべき点が数多くあります。たとえば、多くのアプリケーションは、XMPP やプレーン TCP パケットなど、HTTP 以外のプロトコルを使用したり、MITM 攻撃を阻止しようとするために証明書ピン留めを実行しますが、残念ながら、実装に重大な論理的バグがあったり、セキュリティネットワーク構成が本質的に間違っていることがあります。
多くの場合、静的解析を使用するだけでは十分ではなく、より信頼できる結果を得られる動的解析 (傍受プロキシを使用するなど) と比較すると、極めて非効率的になるかもしれないことを覚えておいてください。このセクションでは、表面を少し触れただけです。基本的なネットワークモニタリング/スニッフィング (Basic Network Monitoring/Sniffing)arrow-up-right を参照し、"Android のネットワーク通信" の章のテストケースもチェックしてください。
Last updated 4 days ago