web-dev-qa-db-ja.com

Androidアプリの中間者攻撃

Androidアプリがあり、強力な認証後にサーバーAから機密データをプルして、保存せずにサーバーBに送信するアプリがあるとします。データはネットワークトラフィック(明らかに暗号化されている)とアプリのメモリセグメント。

問題は:apkを変更して、サーバーAからBに転送されたデータを事前定義された文字列で置き換えるために、なんらかの方法でフックすることは可能か、それとも可能ですか?

クライアント側のセキュリティに依存することは非常に難しいことはわかっていますが、このハック(apkの取得、逆コンパイル、フックする関数の検索、コンパイル、インストール)の複雑さと、可能なショーストッパーについて理解したいと思います。

このシナリオでは、コードの難読化によってどれほど多くのセキュリティを実現できますか?難読化されたコードを逆コンパイルしてリバースエンジニアリングするのはどれほど簡単ですか。

私はAndroidでもJava開発者でもありませんが、セキュリティの概念についてはある程度知っています。

私の答えは、攻撃者がこの種の作業を行う「技術に熟練している」と想定しています。

aPKを取得する

質問を書くよりも時間がかかりません。

逆コンパイル

コンピュータの速度に少し依存しますが、数分程度のはずです。

フックする関数を見つける

あなたがこれを自明でないものにしようとするためにあなたの方法から遠くに行くなら...おそらく1日?アプリのサイズと複雑さ、これが単一の「機能」だけなのか、それとも作業がかなり複雑になるのかなどに大きく依存するため、抽象的に言うのは少し難しいです。

時間をかけたい人は誰でも変更が必要なものを見つけることができると言えば十分でしょう。

コンパイル

コンピュータの速度とコードベースのサイズによって多少異なりますが、ここでも数分で測定する必要があります。

インストール

質問を書くよりも時間がかかりません。

このシナリオでは、コードの難読化によってどれほど多くのセキュリティを実現できますか?

数年前、あるセキュリティ研究者から、単純なProGuard難読化を使用すると、この種の攻撃が実際に簡単になったと言われました。

ProGuardの「兄貴」であるDexGuardなど、より強力な難読化ツールが世の中に出回っています。同様に、難読化解除ツール、つまりDexGuardレベルの難読化をProGuardにより近いものに落とし込むツールを作成する人々がいます。たとえば、DexGuardは可能な限り多くのアプリを暗号化しようとします。難読化解除者は、コードの復号版を生成します。

したがって、高レベルの難読化ツールの利点は、難読化ツールの開発者と難読化解除者の開発者の間の競争の現状に基づいて異なります。私が軍拡競争が今どこにあるのか、私が何年もこの答えを読んだときは言うまでもありません。

私は、森の中で2人のハンターがクマに追われているという昔話に難読化者をたとえます。あなたがハンターの一人なら、逃げるためにクマより速く走る必要はありません。あなたは他のハンターよりも速く走らなければならないだけです。難読化ツールの場合、その目的は、アプリでの煩わしさを魅力のないものにし、攻撃者が他の潜在的に簡単なターゲットに移動するようにすることです。このアプローチの問題は、攻撃者がアプリを特に気にかけず、アプリが多数のターゲットの1つにすぎないと想定していることです。特定の理由でアプリを攻撃することに関心を持つ攻撃者は、そのように振る舞わず、時間をかけてそれを解読します。言い換えれば、他のハンターよりも速く走ることは、クマがあなたに特に腹を立てていないことを前提としています。

1
CommonsWare

AndroidアプリケーションでのMITMの可能性は、指定された順序にあります。

1。 SSL/TLSなし

この場合、MITMを実行するのは非常に簡単です。単に「暗号化」の代わりにSSL/TLSを使用することは意図的でした。 SSL/TLSは「機密性」だけでなく「認証」も提供します。したがって、アプリの通信がHTTPSまたは別のSSLチャネル上にない場合、ネットワークレベルのMITMを実行し、すべての要求と応答を操作することは非常に簡単です。

2。デバイスの信頼された資格情報ストアを使用する

ブラウザーと同様に、Androidデバイスにも信頼できるCAのセットがあります。アプリケーションがSSLを介した認証でデバイスの信頼できる認証情報ストアに依存している場合、[ここではパスワード認証について話していません]、それは次の状況でもMITMに対して脆弱です-a)デバイス認証情報ストアのリストにある信頼できるCAの1つが侵害された、b)攻撃者がカスタム認証局をデバイス認証情報ストアに追加できた-両方とも少なくとも0より大きい確率。

3。 SSLピン留め

SSL pinning は、アプリケーションがデバイスのトラストストア自体の資格情報を使用する方法ですが、CAを利用可能なもののサブセットに制限します。マルウェアによって、これも回避できる方法があります。例は、JustTrustMeのようなCydia Substrate/Xposedモジュールを使用して、Android SSLピン接続を使用するアプリケーションに 侵入テストを実行するためです。

4。カスタム証明書ストアの使用

これは、アプリケーションが独自の証明書ストアを使用する場合であり、すべての情報がAPK自体にバンドルされています。この場合、攻撃者はMITM攻撃を実行するために、アプリケーションを逆コンパイルまたは逆アセンブルし、smaliコードを変更して独自の証明書を追加し、apkを再コンパイルして署名し、t =被害者にそれをインストールさせる必要があります。はい、それはかなり難しいです。

1
hax

AndroidアプリがJava(またはKotlin)で記述されており、難読化ツールを使用していない場合、攻撃は非常に簡単です。専門的な難読化ツールがハッカーを阻止しますが、出力を事前定義された文字列で置き換えることが目的の場合、コードの難読化は実際の保護を提供しません。

アプリはAndroidのオープンソースであるシステムネットワーキングAPIを使用するため、プラットフォームレベルでこれらの変更を行うこともできます。

プロトコルレベルで回答を探す必要があります。両方のサーバーがパケットに署名し、着信パケットの署名を返信に含めると、MitMへの挑戦がはるかに困難になります。

0
Alex Cohn