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

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

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

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

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

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

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. होस्ट-साइड टेस्ट, क्रैश की जांच करता है, logcat बैकट्रैस देखता है या यह पता लगाने के लिए कि हमला हुआ है या नहीं, खास एग्ज़िट कोड देखता है.

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

    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 Vulnerability Reward Program में सबमिट किए गए डेटा के साथ अपलोड करें.