Android Security Test Suite डेवलपमेंट किट (एसटीएस SDK टूल)

Security Test Suite ट्रेड फ़ेडरेशन (sts-tradefed) को Android ट्रेड फ़ेडरेशन के सबसे बेहतरीन टेस्ट हार्नेस की मदद से बनाया गया है. इसकी मदद से, सुरक्षा वाले उन सभी Android डिवाइसों की जांच की जा सकती है जो कम्पैटिबिलिटी टेस्ट सुइट में शामिल नहीं हैं. ये टेस्ट, आम तौर पर होने वाली कमजोरियों और जोखिमों (सीवीई) से जुड़े सुधारों के लिए खास तौर पर किए जाते हैं.

SDK टूल की मदद से, Android Studio या स्टैंडर्ड Android SDK का इस्तेमाल करके, Android सोर्स ट्री के बाहर एसटीएस टेस्ट डेवलप किए जा सकते हैं. इसमें वे सभी सुविधाएं शामिल हैं जो एसटीएस टेस्ट बनाने और चलाने के लिए ज़रूरी हैं.

नया STS SDK टूल पाना

ज़रूरी शर्तें

  • 64-बिट Linux पीसी.
  • Android Studio (इसे आपके Distro के पैकेज मैनेजर से भी इंस्टॉल किया जा सकता है.
  • Android प्लैटफ़ॉर्म टूल (adb, fastboot) इंस्टॉल होने चाहिए और आपके $PATH में होने चाहिए (इसका मतलब है कि आपके पास कमांड लाइन से adb चलाने की सुविधा होनी चाहिए). अपने Distro के पैकेज मैनेजर के ज़रिए, प्लैटफ़ॉर्म टूल इंस्टॉल करने का सबसे आसान तरीका बताया गया है.
    • अगर स्टैंडअलोन प्लैटफ़ॉर्म टूल के बजाय, Android Studio के SDK मैनेजर का इस्तेमाल किया जा रहा है, तो अपने $PATH में SDK की platform-tools डायरेक्ट्री जोड़ना न भूलें.
  • aapt, को आपके Distro के पैकेज मैनेजर के ज़रिए भी इंस्टॉल किया जा सकता है.

Android Studio का इस्तेमाल शुरू करना

संग्रह को एक्सट्रैक्ट करने के बाद, Android Studio में डायरेक्ट्री को एक मौजूदा प्रोजेक्ट के तौर पर खोलें. टारगेट किए गए Android डिवाइस के आर्किटेक्चर के आधार पर, स्केलेटन टेस्ट बनाने के लिए assembleSTSARM या assembleSTSx86 बिल्ड टारगेट चलाएं. कनेक्ट किए गए डिवाइस पर स्केलेटन टेस्ट करने के लिए, runSTS बिल्ड टारगेट चलाएं (ADB के पास अनुमति होना ज़रूरी है).

Gradle का इस्तेमाल करना शुरू करें

संग्रह को निकालने के बाद, Gradle प्रोजेक्ट के रूट में मौजूद local.properties फ़ाइल में sdk.dir प्रॉपर्टी सेट करें. इसके बाद, स्केलेटन टेस्ट बनाने के लिए assembleSTSARM Gradle टास्क चलाएं. बिल्ड पूरा होने के बाद, build/android-sts/tools पर नेविगेट (cd) करके और sts-tradefed रैपर को चलाकर, टेस्ट चलाया जा सकता है.

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

एसटीएस टेस्ट का डेटा सेव करने की अनुमति दें

एसटीएस टेस्ट के तीन हिस्से होते हैं:

  1. एक होस्ट-साइड ट्रेडेड टेस्ट, जो sts-test सबडायरेक्ट्री में, adb की मदद से डिवाइस से इंटरैक्ट करता है.
  2. कॉन्सेप्ट की पुष्टि करने वाला एक वैकल्पिक नेटिव अटैक, जिसे adb push के ज़रिए डिवाइस पर पुश किया जाता है और native-poc सबडायरेक्ट्री में होस्ट-साइड टेस्ट से चलाया जाता है.
  3. ज़रूरी नहीं है कि ऐप्लिकेशन या सेवा का APK, डिवाइस पर adb install के ज़रिए इंस्टॉल किया गया हो. साथ ही, होस्ट-साइड टेस्ट से भी इसे लॉन्च किया जा सकता है. ऐप्लिकेशन या सेवा में, JUnit के ऐसे एश्योरेशन का सेट भी हो सकता है जिनकी जानकारी होस्ट-साइड रनर को दी जाती है. यह test-app डायरेक्ट्री में है.

एसटीएस की जांच का सामान्य फ़्लो, आम तौर पर दो में से एक पैटर्न के साथ होता है:

  • सिद्धांत का सबूत देने वाला नेटिव ऐप्लिकेशन:

    1. होस्ट-साइड की जांच से डिवाइस पर, नेटिव एक्ज़ीक्यूटेबल फ़ाइल को लॉन्च किया जाता है.
    2. नेटिव प्रोग्राम क्रैश हो जाता है या कोई खास एक्सिट कोड दिखाता है.
    3. होस्ट-साइड टेस्ट, क्रैश का पता लगाता है, लॉगकैट बैकट्रेस या किसी एग्ज़िट कोड पर नज़र रखता है, ताकि यह तय किया जा सके कि हमला पूरा हुआ या नहीं.

  • इंस्ट्रुमेंट किए गए टेस्ट ऐप्लिकेशन:

    1. होस्ट-साइड टेस्ट, डिवाइस पर किसी ऐप्लिकेशन या सेवा वाले APK को पुश करता है.
    2. होस्ट-साइड टेस्ट, डिवाइस-साइड JUnit टेस्ट शुरू करता है. ये टेस्ट, runDeviceTest() के ज़रिए APK के साथ बंडल किए जाते हैं
    3. डिवाइस-साइड JUnit, बटन पर टैप करके ऐप्लिकेशन को देखता है और UIAutomator का इस्तेमाल करके ऐसा करता है. इसके अलावा, यह Android सिस्टम को ऐसे तरीकों से ऐक्सेस करता है जिनसे सुरक्षा से जुड़े जोखिम का पता चलता है.
    4. डिवाइस-साइड JUnit टेस्ट सफल या असफल होने की जानकारी, होस्ट-साइड टेस्ट पर दी जाती है. इससे यह पता लगाया जा सकता है कि टेस्ट पास हुआ या नहीं.

दोनों पैटर्न को एक साथ भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, डिवाइस-साइड टेस्ट के साथ नेटिव प्रोग्राम चलाना. कुछ अन्य इंस्ट्रुमेंटेशन फ़्रेमवर्क, जैसे कि frida-inject भी उपलब्ध हैं. ज़्यादा जानकारी के लिए, Security Test Suite के रेफ़रंस दस्तावेज़ और Tradefed के रेफ़रंस दस्तावेज़ देखें.

मेरे प्रूफ़-ऑफ़-कॉन्सेप्ट अटैक के लिए किसी टेस्ट ऐप्लिकेशन या नेटिव एक्ज़ीक्यूटेबल की ज़रूरत नहीं है

ज़्यादातर जांचों के लिए डिवाइस-साइड ऐप्लिकेशन और मूल एक्ज़ीक्यूटेबल ऐप्लिकेशन, दोनों की ज़रूरत नहीं होगी.

अगर आपके टेस्ट में डिवाइस पर मौजूद ऐप्लिकेशन/सेवा का इस्तेमाल नहीं किया जा रहा है, तो test-app सबडायरेक्ट्री को मिटाएं. इसी तरह, अगर आपका टेस्ट किसी नेटिव रनटेबल का इस्तेमाल नहीं करता है, तो native-poc सबडायरेक्ट्री मिटाएं. इसके बाद, प्रोजेक्ट को Gradle के साथ सिंक करें. प्रोजेक्ट को इस तरह सेट अप किया गया है कि अगर वे मॉड्यूल मौजूद नहीं हैं, तो उन्हें अपने-आप बिल्ड न किया जाए.

मेरे कॉन्सेप्ट की पुष्टि करने वाले हमले में, दूसरे ऐप्लिकेशन/सेवा का इस्तेमाल किया गया है

सबसे पहले, अपने दूसरे ऐप्लिकेशन/सेवा के लिए अपने प्रोजेक्ट में नया मॉड्यूल जोड़ें और उसे किसी अन्य APK की तरह लिखें.

इसके बाद, इस डायरेक्ट्री के रूट में मौजूद build.gradle में बदलाव करें. साथ ही, copyArtifacts, assembleStsARM, और assembleStsx86 में दिए गए निर्देशों का पालन करके अपना मॉड्यूल जोड़ें. इससे यह पक्का होगा कि कंपाइल किया गया APK, STS के आउटपुट डायरेक्ट्री में कॉपी हो गया है और नए ऐप्लिकेशन को इंस्टॉल या कॉल करने की प्रोसेस चालू हो जाएगी.

आखिर में, प्रोजेक्ट को Gradle के साथ सिंक करें.

एसटीएस टेस्ट सबमिट करें

zipForSubmission टास्क चलाएं (इसे Android Studio या कमांड लाइन में Gradle के साथ) इस्तेमाल किया जा सकता है. प्रोजेक्ट के रूट में मौजूद build डायरेक्ट्री में, codesubmission.zip नाम की एक नई फ़ाइल बनाई जानी चाहिए. वह फ़ाइल भी अपलोड करें. साथ ही, उसे 'Android के जोखिम की आशंका के लिए इनाम कार्यक्रम' के लिए अपने सबमिशन के साथ अपलोड करें.