AndroidセキュリティのHttps仲介者が脆弱性を攻撃

2752 ワード

メッセージを送る脆弱性の適用 and roid https androidに関する質問

0 X 01概要

HTTPSは、SSL/TLSを利用してパケットを暗号化し、ネットワークサーバのアイデンティティ認証を提供し、交換データのプライバシーと完全性を保護するネットワークセキュリティ伝送プロトコルである.仲介者攻撃、Man-in-the-middle attack、略称:MITMとは、攻撃者と通信の両端がそれぞれ独立した連絡を作成し、受信したデータを交換し、通信の両端がプライベートな接続を通じて相手と直接対話していると思っているが、実際には会話全体が攻撃者に完全に制御されていることを意味する.httpsは理論的にはMITMを防ぐことができるが、開発中の符号化が規範化されていないため、httpsにはMITM攻撃リスクが存在する可能性があり、攻撃者はhttpsデータを復号、改ざんすることができる.

0 X 02 http脆弱性

Android httpsの開発過程でよく見られるセキュリティ上の欠陥:1)カスタム実装X 509 TrustManagerの場合、checkServer Trustedで証明書が信頼できるかどうかをチェックしていないため、通信中に仲介者の攻撃が発生し、機密データのハイジャックの危害をもたらす可能性がある.2)WebViewClientのonReceivedSslErrorメソッドを書き換える場合、proceedを呼び出して証明書検証エラー情報を無視してページをロードし続け、通信中に仲介者攻撃が発生し、機密データハイジャックの危害をもたらす可能性がある.3)カスタム実装HostnameVerifierの場合、verifyで厳密な証明書検証が行われず、通信中に仲介者攻撃が発生し、機密データハイジャックの危害をもたらす可能性がある.4)setHostnameVerifierメソッドでALLOW_を使用するALL_HOSTNAME_VERIFIERは、すべてのHostnameを信頼し、通信中に仲介者の攻撃が発生し、敏感なデータハイジャックの危害をもたらす可能性がある.

0 X 03脆弱性事例

ケース1:京東金融MITM脆弱性京東金融Ver 2.8.0証明書検証に欠陥があるためhttps仲介者が攻撃し、攻撃者はセッション中の機密データの暗号化鍵を直接取得することができ、またAPPはアプリケーションの強化や混同をしていないため、復号アルゴリズムを簡単に分析し、取得したkeyを利用して機密データを復号することができる.安全スキャンの結果:
以下に、ログイン時に取得したデータを示します.
このsecretkeyは、APPで対称暗号化が使用されているため、攻撃者はすべての通信データを復元することができる後期通信中の機密データを暗号化するために使用されます.ケース2:中国移動とパッケージの任意消費の抜け穴HTTPS証明書の検査は厳格ではなく、MITMにされることができる.暗号化アルゴリズムは安全ではなく、解読することができる.重要なデータはsdcardカードに保存され、任意にアクセスできます.コードの混同度が低く、業務ロジック、重要なデータの漏洩;メッセージ署名アルゴリズムは比較的簡単で、データは修正することができる.通信データは次のとおりです.

POST https://mca.cmpay.com:28710/ccaweb/CCLIMCA4/2201194.dor HTTP/1.1
Cookie: JSESSIONID=CHGmYSZLTMRAx_1sSEuUP6Q4vmRI9gWiRPM6ANGnH7eZWv0NhErE!221531807
.......
Content-Length: 521
Host: mca.cmpay.com:28710
Connection: Keep-Alive
Cookie: JSESSIONID=CHGmYSZLTMRAx_1sSEuUP6Q4vmRI9gWiRPM6ANGnH7eZWv0NhErE!221531807
Cookie2: $Version=1
866697029909260201603241008185gye5tKk6EPB4iliO722011944.3.82Android_21-1794*1080-HUAWEI GRA_UL1020093CAS000169918666970299092601050:a7:2b:c5:e2:d8

ユーザーが秘密の支払いを免除する前提の下で、以上の安全問題を結びつけて、現地あるいは遠隔攻撃を実現することができて、直接ユーザーの資金を盗んで包んで、例えば任意のアカウントにチャージするなど、ユーザーに直接の経済損失をもたらします.

0 X 04安全提案

1)カスタムインプリメンテーションX 509 TrustManagerを推奨する場合、checkServer Trustedでサーバ情報を厳密に検証する2)WebViewClientのonReceivedSslErrorメソッドを書き換える場合、proceedを呼び出して証明書検証エラー情報を無視してページをロードし続けることを避ける3)カスタムインプリメンテーションHostnameVerifierの場合、verifyでHostnameを厳密に検証する4)setHostnameVerifierメソッドでSTRICT_を使用することを推奨するHOSTNAME_VERIFIERは厳格な証明書検査を行い、ALLOW_の使用を避けるALL_HOSTNAME_VERIFIER

0 X 05参照

https://en.wikipedia.org/wiki...https://en.wikipedia.org/wiki...http://drops.wooyun.org/tips/...(テンセント御安全技術ブログ)

2 lv N個の最小公倍数

連続的な統合(CI)ローカル